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Dave Packard's idea for the HI' Journal originated with a publication called the Experimenter, 
published by the General Radio Company. "I remember drooling over the Experimenter when 
I was in high school." Dave told Karen Lewis, HP's archivist and historian. Featuring an article 
entitled "A New Amplifier for Milli-Microsecond Pulses." the MP. Journal made its debut in 
September, 1949. 

Packard believed the Journal's role was to describe the technology used in the development 
of important HP products, and that it should be a vehicle for sharing such information with 
the larger engineering community. He also felt the Journal should recognize the contributions 
of individual HP engineers to the company and the electronics industry. Forty-seven years 
later, on the occasion of Dave Packard's passing, we at the Journal are still dedicated to those 
goals. 
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What's Ahead 

The first six articles in the August issue will describe HP's current software engineering practices. Five of the 
articles are from HP's Corporate Engineering software initiative group and one article is from HP's Software 
Engineering Systems Division. There will also be five articles from HP's 1995 Electronics Packaging and Man- 
ufacturing Conference. 
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In this Issue 



The most unpredictable and time-consuming pan of developing a complex digital sys- 
tem is the system integration phase. During system integration, the various hardware 
and software subsystems finally come together for the first time. Although the inter- 
dependencies between the various subsystems have been simulated, emulated, and 
unit tested before system integration, there are always surprises These surprises, or 
"hard problems," (page 6) dramatically affect the time-to-market goals for the product. 

To find the root causes for these hard problems, engineers need to see what is going 
on in several subsystems (e.g., operating system, memory, I/O, etc.) at once. The article 
on page 15 describes a tool that assists engineers in the search for root causes The 
tool is called the HP 16505A prototype analyzer. The HP 16505A is an XI 1/Motif application that runs on an HP 
9000 Model 712 workstation connected to an HP 16500 logic analyzer. This configuration provides a graphical 
user interface (GUI) that enables users to create a measurement setup using icons that represent HP 16500 
hardware modules and HP 16505A software modules. The software modules display or list the time-correlated 
data from the instruments in a variety of formats. To deal with the variety of data types from the instruments 
and the data uniformity requirements of the analysis and display modules, data is normalized immediately 
after acquisition and made available to all the output modules in a standard format (page 30). The selection of 
the encapsulated measurement server architecture of the HP 16505A (page 22) was based on feedback from 
an analysis of customer needs and requirements. 

Allowing targeted users to participate in the design of a product is the best way to focus product goals and 
hopefully produce a successful product The HP 38G graphing calculator (page 45) is a calculator designed 
for precalculus students and their teachers. In addition to the typical HP design team, an Educational Advisory 
Committee consisting of high school, community college, and university teachers was formed to help in de- 
signing this product. The HP 38G is built on the same software platform as the HP 48G graphing calculator, so 
it has many of the capabilities of the HP 48G but with a simpler user interface and a capability called aplets. 
An aplet (page 59) is a small application that focuses on a particular problem. Thus, teachers can keep students 
focused on a particular scientific or mathematical concept (e.g., polygons) by creating and downloading a set 
of aplets for students to work on. 

HP OmniBook computer users are used to the idea of having a small mobile computer with some of the same 
capabilities and applications as their desktop machines. However, with features such as color displays, larger 
hard drives, and faster processors appearing in the HP OmniBook family of notebook computers, the expecta- 
tion is to have a full-featured notebook computer with the same capabilities as desktop computers (of course 
not with the same performance as the high-performance desktop models). The article on page 38 describes the 
HP OmniBook 5000, which is a full-featured notebook computer based on the Pentium ' processor. This product 
is designed to satisfy the demand for a notebook computer with complete desktop computer capabilities. 

Today's mobile paging systems allow people to keep in 24-hour contact. One group of people who especially 
need this kind of service are physicians caring for critically ill patients They need access to all the clinical 
patient information (graphical and textual) no matter where they are. The HP PalmVue system (page 64) fulfills 
this need by allowing the transmission of clinical patient information via conventional alphanumeric paging 
systems. The system integrates computer networks, palmtop computers, paging systems, and physicians who 
use HP monitoring systems and cardiographs to deliver high-quality patient data to mobile physicians. 

HP divisions are always trying to find tools and processes to increase productivity and improve the quality of 
products. The last two articles in this issue describe efforts aimed at these quality and productivity goals. The 
first article (page 70) describes a tool that helps system administrators deal with installing and maintaining 
applications in an environment where there are hundreds of workstations and servers. The second article 
(page 76) describes software translators that facilitate the development of programs consisting of high-level 
C-language modules and low-level assembly-language modules. Such dual-language programs are common 
when old software modules are reused. 

C.L Leath 
Managing Editor 

Pentium is a U S trademaik ol Inlet Corporation 

QSF. Mulit. and Open Software Foundation are trademarks ot the Open Software Foundation in the U S A and other countries 
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Reducing Time to Insight in Digital 
System Integration 

Digital design teams are facing exponentially growing complexities and 
need processes and tools that reduce the time needed to gain insight into 
difficult system integration problems. This article describes modern digital 
systems in terms of the problems they create in the system integration 
phase. The debug cycle is described with special emphasis on the "insight 
loop," the most time-consuming phase of system integration. A case study 
from an HP workstation design effort is used to illustrate the principles. 
A new digital analysis tool, the HP 16505A prototype analyzer, is introduced 
as a means of solving these vexing problems more quickly by reducing 
time to insight. 

by Patrick J. Byrne 



The digital (evolution is upon us in every form. Computer 
performance doubles every 18 months. Networks of high- 
performance servers are replacing mainframes at a dizzying 
pace. Personal communication systems are pervasive, from 
remote sales tools to medical information systems to net- 
worked workgroup tools. 

What is behind this revolution? The answer is hardworking 
teams of engineers focused relentlessly on reducing time to 
market with the latest silicon and embedded systems. These 
teams of engineers are taking the latest silicon technology in 
ASIC's (application-specific integrated circuits ) and memory, 
exploiting them while adding value in the form of special 
application-focused architectures and implementations, and 
bringing the end products to market at the right lime, price, 
and performance. These efforts are often made up of highly 
integrated subteams of four to eight engineers — hardware 
development specialists with expertise in ASIC design, 
printed circuit board system design, hardware architectural 
trade-offs, and the latest CAE (computer-aided engineering) 
tool methodologies. These teams specialize in designing 
high-performance, efficient, embedded software systems 
using the latest software design tools and languages. It is not 
unusual for design teams to use C++ and to have a carefully 
Ciafted multilayer software system with de facto APIs (ap- 
plication programming interfaces) between layers. These 
abstractions are used to manage the growing complexities 
of real-time embedded systems. These teams have to keep 
the customer in clear view as I hey make complex trade-offs 
between software and hardware implementation, between 
time to market and feature sets, between material cost 
(hence customer price) and component sourcing risks. 

Concurrent Design and the Integration Phase 

Figs, 1 and 2 illustrate the nature of the modem digital design 
process. Fig. 1 shows how the many competencies are 
brought together by the design team into the end product. 
The modem digital design process is highly concurrent. To 



make progress, each engineer makes assumptions about the 
other engineers' work. Sometimes these assumptions are 
well-documented, but often they are not because of the 
relentless schedule pressures. The risk accumulates through- 
out the design process because the tools used by different 
members of the design team rlo not explicitly articulate the 
interdependencies between subsystems. These design inter- 
dependencies are often found in the integration phase, when 
the whole design comes together for the first time. This is 
the well-known finger-pointing phase. "It's a hardware prob- 
lem," says the software engineer. "It's a software problem," 
says the hardware engineer. The team members then sort 
out the problems from their respectiv e points of v iew, en- 
gaging in the iterative and unstructured debug process. 

Fig. 2 shows this development process in terms of cycle 
limes. Twenty to thirty percent of the entire development 
process time is used in this unstructured integration phase. 
This phase of the design process is unstructured because 
there are so few well-designed tools and processes for engi- 
neering teams to use to work through the key integration 
tasks. In the integration phase, hardware meets hardware in 
the form of ASICs interacting with the circuit board. Inter- 
hardware design and modeling flaws are found here. Hard- 
ware meets software in the form of driver code running 
ASIC subsystems. There are also problems from application 
programs causing software integration problems. Application 
code provides an incredibly rich and complex stimulation 
system to the hardware. 

Hardware and software modeling tools (simulators, compil- 
ers, logic synthesis, etc. I falter in their ability to model all 
these complex combinations, sequences, and data and code 
interdependencies. Fig. 3 shows the simulation execution 
speed of a typical 40-MHz system. Most digital circuit simu- 
lators execute at 10 to .'10 cycles per second, leading to total 
system simulation times of days and sometimes weeks. This 
is too long for designers who are used to the iterative design 
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and debug process. Tliis show s thai siniulalors arc just loo 
slow to expose real-world problems w ithin the mental time 
constants designers need. 

Hard Problems in the Real World 

This rich and complex environment is the real-world envi- 
ronment indicated in Fig. 2. The modeled world in Fig. 2 is 
w here designers work in isolation to predict real-world 
behavior. Bui it is very hard to predict every comer case to 
which the actual applications will lake complex Combina- 
tions of hardware ;uid software. The real-world environment 
is the domain or the "hard problems." also called the "inter- 
esting cases" by some engineers. The software team has 



done their best to model the hardware. They have read the 
hardware documentation and written their driver and appli- 
cation code consistent with these models. The hardware 
engineers have done their best to model the software. Often, 
hardware engineers w ill standardize hardware interfaces 
specifically to av oid unmodeled software behavior. However, 
when the team puts the system together, they find unmodclf d 
or undermodcled cases — the interesting cases. They find 
that their documentation doesn't cover some sequence of 
behavior by which the application code runs the ASIC into a 
state machine or switc hing condition that causes a glitch 
that delays response, causing the software to lime out at the 
ft mil h layer of the protocol. It is very common to have the 
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Fig. 3. Time required to simulate one second of operation in a 
-10-MHz system. 

problems in the real world be separated, symptom from root 
cause, both temporally and spatially. For example, an ASIC 
on a peripheral bus has a state machine sequence that causes 
an eiTor condit ion, but the errored packet is not sent back to 
the CPU until it fits into the priority stack. Or even more 
simply, the bad data is written to memory a long time before 
it is read and found to be faulty. The problem is detected 
later in time and at a different point in the system from 
where and when it was caused. Multiple bus architectures, 
such as Peripheral Component Interconnect (PCI), using 
intelligent queueing techniques, make these kinds of laten- 
cies commonplace. 

Another common real-world problem is the infrequent prob- 
lem that only happens at odd. nonrepeatable times because 
complex hardware and software systems have deep memory 
capacities anrl latencies in registers and state machines in 
addition to complex logical extent. The hard problems are 
those that the system stimulates through complex interac- 
tions between big application systems and deeply sequenced 
complex hardware systems. Odd pairings of hardware and 
software states cause infrequent behavior. Every engineer 
knows the problem of solving an infrequent system crash. 

Another common real-world problem is the hidden depen- 
dency. This is caused by underspecified subsystems working 
together at blinding speeds. It is just not possible to specify 
every hardware or software component's ultimate use. Envi- 
ronmental conditions like temperature or application loading 
stress the system to expose these hidden dependencies. The 
case study described later in this article will show how sim- 
ple and "perfectly specified" TTL parts can be the root cause 
of a very nasty operating system crash. This is typical of the 
hard problems. 



Complexity: Growing Exponentially 

The root causes of these kinds of vexing problems are hard 
to anticipate and hard to find. They delay projects and defy 
schedule prediction for managers. The reason they are so 
common is the exponentially growing complexity of today's 
systems. Silicon allows systems with 50,000 to 100.000 gates 
to be combined with ;l2-bit GPU architect tires wilh out-of- 
order execution and large on-chip caches, controlled by 
3M-to-10.M-byte embedded software systems. These soft- 
ware systems are designed carefully with multiple layers of 
functionality to promote reuse and maintainability. These 
software layers, combined with poor code execution visibility 
because of caches and queues, can create indirection and 
poor observability during the integration phase. 

Fig, 4 illustrates the exponentially growing complexities of 
today's subsystems. ASIC integration allows entire subsys- 
tems to be placed beyond the eyes of probes. Modem CPL's 
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have 10 million transistors and multiple execution units. 
Embedded systems grow as well. All these technologies are 
brought to bear at varying levels of risk to be competitive 
today. Teams must master not only the individual technolo- 
gies but their inevitable integration. The complexity" simply 
overwhelms. It is very difficult for engineering teams to pre- 
dict all the interdependencies between such complex sub- 
systems. Few engineers on a team understand enough of the 
details of each technology to predict the conditions that will 
cause a failure during integration. Engineers have to know 
their design tools: what they do right and what they do 
wrong. They have to know the system functionality and how 
it reflects down to the details of their design and the design 
of the next engineer. They have to know how to unravel the 
odd sequence of events that causes the infrequent system 
failures. Most hard problems must be solved by teams of 
engineers because the complexities of the interactions cross 
engineering disciplines. 

Iterative Debug Loop 

The process used by engineers to solve these complex inte- 
gration problems that have eluded their design tools is illus- 
trated in Fig. 5. The engineers start in the upper right corner, 
identifying the problem first by clarifying the symptoms. 

The next step in the process, isolating problems correctly, is 
often tricky. Rumors and "old problems — old solutions" 
confuse. It is very common to jump to conclusions based on 
symptoms because the engineer once saw a problem like 
this before and solved it in a certain way. The correct ap- 
proach is to perforin what doctors call a differential diagno- 
sis — describing in detail and with accuracy what has changed 
from the correctly working condition that could cause a 
problem, thereby isolating the unique operational sequence, 
litis lakes discipline and careful analysis. 

The next phase is to discover the hardware or software de- 
pendencies that consistently describe the unique configura- 
tions and sequences to describe the problem correctly. 
Sometimes a binary search technique is used: code is sliced 
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apart and patched back together to stimulate the hardware 
to the unique and small code segment that reliably repeats 
the problem. Experience and intuition are very important 
hen? because hard problems seem to have classic root causes 
but a variety of symptoms, discovered over and over by each 
generation of engineers. Yet the process must be data-driven 
so that the team is not led to false conclusions. 

It is often the case that only one in twenty engineers can 
correctly isolate the dependencies and sequences. This is 
because few people are chartered with the task and have the 
experience to understand the total picture of how a system 
works in enough pervasive detail to lead structured detective 
work. The next phase in the debug cycle is finding the true 
root cause. Infrequent problems, large unobservable ASIC 
systems, complex software systems, and time pressures 
make this task difficult. But it is very' important to find the 
true root cause or a simple fix will unravel when some bid- 
den dependency is invoked. A new solution causes another 
problem. A small change in temperature, voltage, or applica- 
tion loading will cause the fix to stress to the breaking point. 
Margins will be broken. This is the "insight loop": the struc- 
tured detective work needed to synthesize the true root 
cause from confusing and overwhelming data sets caused by- 
vast complexities. The ability to reach the true root cause 
rapidly and explain the symptoms, dependencies, legacies, 
and sensitivities is an art form and is deeply insight-based. 

The root cause phase leads to the verification phase, in 
which the suspected fix is patched in and lesled to see if it 
works in all cases. Often design members will go back to 
their design tools (simulators, etc.) to verify a fix because 
design tools provide a much richer method for controlling 
stimulation variables than Ihe real world. It is hard Co con- 
trol a train wreck! The design team works hard to recreate 
exactly the parameters that caused the problem, and then 
they look for oilier related problems and symptoms. I'nfor- 
tunalely. a patched fix often breaks the system in a new way, 
causing new problems to occur. Or worse, the root cause 
was wrong and the fix doesn't work. Then the team starts 
over, having "wasted" time solving the wrong problem or 
only partially solving Ihe right problem. 

Required Tools and Processes 

The time it takes to solve these complex problems currectly 
is highly variable and highly sequential. Therefore, it is very 
hard to predict or reduce this time systematically. The vari- 
ability conies from the inner loop, called the insight loop. 
This is where the engineers labor over the vast complexities 
and try to connect detailed hardware and software compo- 
nent-level understanding with rich and complex sequences 
and interactions. The engineering team must traverse from 
operating system to switching sequences to solve the prob- 
lems. They need tools that traverse these levels of design 
hierarchy and the attendant complexity in a way thai pre- 
serves context but reveals details. The engineer lHUSl retain 
detailed understanding but in the context that describes the 
problem, always performing Ihe deconvolutions I hat slice 
Ihe problem into the subeontext. This is the great challenge 
of the insighl loop. 

The oilier reason for the long integration lime is thai prob- 
lems are uncovered sequentially. One problem is solved and 
then another is uncovered. An operating system must boot 



© Copr. 1949-1998 Hewlett-Packard Co. 



June l696Hev4et^PaclcaRlJ6anul 9 



before a critical performance bottleneck can be discovered. 
A clock distribution problem must be fixed before a bus 
timing problem is tackled, and so on. 

To be competitive, design teams must use the latest technol- 
ogies to get to the price/performance or sheer performance 
they need. The underlying technology pace causes the com- 
plexity, which causes the long integration phase. The design 
learns that master the integration phase are the first to mar- 
ket, since few companies have a sustainable advantage in 
underlying technologies. The winning design teams are able 
lo master this phase consistently over several product gen- 
erations while bringing unique architectures and implemen- 
tations to important customer needs. Saving 20% of a design 
cycle may not seem like much, hut doing this four times in a 
row places the team fully one generation of products ahead 
of its competition, a crushing advantage in today's electron- 
ics markets. This is illustrated in Fig. 6. With product life 
cycles in the fi-to-lS-month time frame, Victors and van- 
quished are determined in just a few- short years using this 
logic. The complexity is the blessing and the curse, the en- 
abler and the nemesis for competitive market entry. 

Design teams need processes and tools to manage this com- 
plexity during the integration phase so that they can. with 
confidence, take one step more in the use of modern tech- 
nologies without going too far. Reducing the lime to insight 
in the insight loop is how teams can master complexity 
rather than have it curse their design cycles with long and 
unpredictable times. The masters of the integration phase 
will win over the long term. These are the winning design 
teams. The tools and processes they need simultaneously 
provide insight into problem dependencies, reducing the lime 
required to isolate the context, and solve multiple problems 
at once. Therefore, these tools must retain context while 
revealing details, and must not hide one problem with the 
symptoms of another. Without the right tools and processes, 
teams will suffer through multiple insight loops in sequence. 

The Hard Problems: Summary 

To summarize the nature of the hard problems and the de- 
bug process so that they remain in focus during the case 
study to follow, the hard problems are listed here in order of 



common occurrence and degree of pain to the digital design 
team: 

• Hardware-software integration. Different tools used by 
different engineers. Very complex interactions. Data depen- 
dent. 

• Displaced locality. Symptom is separated from root cause in 
location and time. 

• Infrequent. Har d to repeat because of deep legacies in 
hardware and software subsystems. 

• Hidden dependencies. L'nderspecified components find the 
corner cases. 

The tools and processes needed in the insight loop provide 
the following: 

• Design hierarchy traversal. Details are shown in the unique 
context that causes them. 

• Correct isolation. The true and unique context of a problem 
is found using sequential exploratory logic. Symptoms are 
explained. 

• Correct root cause analysis. The component-level source of 
the problem Ls found. 

• Verification of proposed fixes, making it possible lo move 
on to the next problem with confidence. 

• Accuracy. One problem is not hidden with the symptoms of 
another. 

HP Workstation Case Study 

Following is a case study from an HP development to illus- 
trate the above principles. Hewlett-Packard is a heavy user 
of advanced technologies and tools to br ing high-perfor- 
mance products to market. The product developments are 
typically organized in integrated design teams that effec- 
tively design complete products. Therefore, HP is a good 
place to look for the challenges and best practices associ- 
ated With the hard problems of complex systems. The case 
study presented here is described in significant detail in 
reference 1. Here it will be used to illustrate the nature of 
the hard problems and the iterative debug process (the 
insight loop) and the need to reduce the time to insight. 

The case study is from the HP workstation group. The target 
system is one of the HP 9000 Series 700 high-performance 
HP-UX* workstations. The block diagram is shown in Fig. 7. 
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Years 

Fig. 6. The cumulative effect of reducing design eyrie limes from 

two years ( bottom) to 1.5 years (middle) is equivalent to increasing Fig. 7. Block diagram of an HP workstation showing the local ion 
the performance of each product generation, as exemplified by the of the ground bounce causing the problem described in die case 
top curve. study. 
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It has a multiple-bus architecture with several custom ASICs, 
and was designed specifically for high performance at a low- 
cost. During the filial product qualification phase, an operat- 
ing system crash was found by a test engineer who was veri- 
fying various hardware and software configurations. The 
problem was infrequent and hard to duplicate. The system 
just crashed at odd times. The test engineer called together 
a team of engineers with the ability to traverse the design 
hierarchy with acumen. 

The first slep was to identify' the problem correctly. The team 
found that the operating system crashed only when the sys- 
tem was performing DMA (direct memory access ) Iransfers 
from a SCSI drive on the EISA bus. The next step was dupli- 
cating and isolating the problem. It could have happened 
anywhere from the data source on the EISA card to the 
DMA cycle termination at the CPU bus. To isolate the prob- 
lem, the data transfers had to be reduced in size and made 
repealabk'. This is where the software team got involved, 
since (hey could assist in slicing the data sets into pieces 
that might recreate the problem. A binary search ensued, 
cutting and trying different data sequences until repeatability 
was achieved with a minimum failing sequence (MPS). Even 
this arduous trial-and-error process .yielded only 90% repeat- 
ability. The 10% nonrecurrence was ultimately tracked to a 
DRAM refresh cycle that changed the timing of the sequence 
that caused the failure (all symptoms must be explained to 
ensure that a true root cause has been found. Often, teams 
will neglect inconv enient tacts. ) The team was now deeply 
in the insight loop, trying to find the sequences and context 
that would isolate the problem, leading them to the root 
cause. 

The next step was to probe all data transfers from the EISA 
card into and out of main memory. For (his (ask, they needed 
a logic analyzer and multiple, time-correlated, probing points. 
They looked through many large (lM-byte) data sets (o find 
the failing sequences. Comparing data across the bus bridges 
is time-consuming, since the latencies are variable as a result 
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Fig. 9. The root cause Of the problem was found with a high-speed 
osi illosropc tinie-correlaterl to the logii analyzer trigger looking at 
the error detecting logic in the CPU, 

of the intelligent queuing techniques employed in the bus 
bridge ASICs. Fig. 8 shows how the four bus transfers were 
observed to isolale the failing transfer. Finally, it was found 
thai the MFS was isolated to memory writes and reads 
across the bus transceivers in the main memory system. The 
suspect part became a TTL bus transceiver, a common pail 
"well-specified" by multiple vendors. The root cause of the 
problem was found with a high-speed oscilloscope time- 
correlated to the logic analyzer trigger looking at the error 
detecting logic in the CPU, as shown in Fig. °. 

The rool cause was ground bounce inside the TTL part. A 
particular sequence of events placed the TI'L part in a situa- 
tion where a write enable to memory was asserted and 
directly followed by the simultaneous switching data transfer 
of the entire byte (Fig. 10). While this seems normal and is 
indeed within specifications, the closeness of the switching 
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Fig. 11. IIP 16B05A prototype 
analyzer. 



events, combined with the initial state conditions and the 
weak ASIC drive circuit nuances and memory system capae- 
itive parasitics, caused a 2-to-3V ground bounce inside the 
TTL part This caused the pail to open up both bidirectional 
buffers, which caused temporary oscillation, which caused 
data corrupt ion. This corrupt data, when read back to the 
CPU many cycles later (several microseconds in a (50-MHz 
design), caused the operating system to crash. 

In the end. all symptoms were explained. Redesigned TTL 
pails were used and the memory system layout and the ASIC 
buffer design were improved. The breadth of experience and 
measurements needed to solve the problem was significant 
and is a true illustration of the insight loop. Vast data depen- 
dencies and odd sequences had to be explored and sliced 
through to find the MFS. Multiple points in the system had 
to be probed in time correlation. Data transfers had to be 
compared across bus bridges. In the end, the entire design 
hierarchy had to be traversed, from the operating system 
crash to the ground bounce triggered by data dependent 
signal integrity. To solve the problem, the entire design team 
had to be involved: the board designer, the ASIC designers, 
the software engineers, and the component engineers. 

The Prototype Analyzer 

The HP Model 16505A prototype analyzer, shown In Fig. 11. 
is a prototyping tool designed specifically to reduce the time 
to insight into the common and complex problems plaguing 
complex digital systems. The prototype analyzer architec- 
ture is described in the article on page 15. It is based on a 
measurement server architecture, described in the article 
on page 22. It is further based on the key concepts of smart 
data exploration, through a logically rich post capture filter- 
ing capability, as illustrated in the case study and in the ar- 
ticle on page 15. The key software technology that allows 
the product to present multiple time-correlated views across 
the design and measurement hierarchy is called normalized 
data and is discussed in detail in the article on page 30. 



The key concepts of the prototype analyzer product are as 
follows: 

Insight into problem sources comes from the time sequence 
dependencies and is facilitated by sequential ordered explo- 
ration tools (filters). Therefore, lime correlation, using 
global time markers, across measurements and across 
measurement domains is critical. Use of color and flexible 
user-definable data organization is required to aid the deep 
insights required to solve the hard problems. 
Most important problems are rare in occurrence. Therefore, 
the tool must quickly and intelligently filter out and elimi- 
nate large data sets that don't relate to the problem at hand. 
Furthermore, since the hard problems are rare, the tool 
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must be able to keep data around to postprocess in every 
conceivable way to extract the maximum use from the valu- 
able captured data (the cause is in there someplace! ). Avoid- 
ing the rerun penalty with its associated time delay keeps 
problem-solving times short, the way engineers need them. 

« Hani problems are solved by design teams, not by single 
members only. Therefore, the measurement server architec- 
ture needs to reside on the network and allow offline analy- 
sis by multiple members. Fig. 12 shows a common configu- 
ration of the prototype analyzer on a network, accessible to 
every design member. The easy communication of informa- 
tion across a local area network using standard file and 
server protocols facilitates team solving processes. Further- 
more, the tool needs to provide team-member-centric views 
appropriate to each person and problem. For this reason, 
the HP 16505 A prototype analyzer provides source-to-signals 
correlation, allowing correlated views from C source code 
10 analog signals, all based on time-correlaied measure- 
ments. The 16500B logic analysis system supports all these 
measurement modalities. 

i Designers have vast intellectual property vaults in their 
design databases. These form the basic raw material for an 
engineer's analysis needs. They must be viewable and com- 
parable to the measured data to accelerate time to insight. 
A file in. file out capability facilitates the easy movement of 
the critical data sets to where they can be manipulated with 
the best postprocessing tools available. Engineers have 
their favorite tools and the prototype analyzer accesses 
thent all through the XI 1 Window interface. 
Large data sets are difficult to use to find the elusive root 
cause of a problem even if the problem has been captured 
in the data set. This is because the user is overwhelmed by 
the magnitude of the data and has to wallow around in it 
Overview tools are needed that transform the low-level digi- 
tal data and software code to a higher level where users can 
see the data that lies outside the norm. The human eye easily 
distinguishes such signals. The user wants to see changes in 
the data rather than just the raw data. This higher level is 
called the modulation domain and is a specialty of the 
prototype analyzer with its ability to create new labels from 
combinations of raw incoming data. An example of this is 
shown in Fig. 13. The analyzer is used to extract setup times 
on a bus from the raw incoming data and clock signals. 
A new label is created from the difference between the data 
and the clock. This label can then be displayed as it changes 
over large time constants using the chart tool. A user can 
easily view a million setup times over several milliseconds. 
Dramatic changes of setup time at periodic intervals tell the 
engineer that the system timing margins are being stressed 
on software time constants, perhaps as a result of a DRAM 
refresh or the servicing of a periodic interrupt. This display 
of the modulation domain is unique to the prototype analyzer 
among digital analysis tools and illustrates the power of 
postprocessing large data sets in overview displays to guide 
an engineer towards the elusive integration problem. 

Prototype Analyzer Solution 

Now we revisit the HP workstation case study to see how 
the prototype analyzer can solve this problem much faster. 
The problem in the target system only occurred when simul- 
taneous switching occurred on the data lines with write 
enable followed quickly by data write changes (refer again 
to Fig. 10). Fig. 14 shows how the prototype analyzer can be 
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Fig. 13. In the modulation domain, changes in the data, rather 
than just raw data, can be observed. In this example, the prototype 
analyzer extracts setup times on a bus from the raw incoming data 
and clock signals and then displays changes in setup time using the 
chart tool 

used with postprocessing filters to isolate the case much 
faster. The prototype analyzer is able to filter out states that 
follow specific sequences. In this case, Filter 1 in Fig. 14 
could be set to view only the data for cases in which all 
states changed from ones to zeros (FF to 00) or vice versa. 
The design team suspected simultaneous switching noise in 
their design and this technique would have quickly given 
them the opportunity to explore this possible root cause 
without rerunning the target system. Any logic analyzer can 
find the first case of FF followed by 00, but only the proto- 
type analyzer can scan an entire onc-megasample record, 
find all the cases where this is true, and display them all 
with the original data, time correlated with other views, such 
as analog data Showing all the data, rather then just trigger- 
ing on the first occurrence of this transition, allows the de- 
sign team to find the one in a million times that this transi- 
tion causes the failure, rather than having to keep 
retriggering the logic analyzer, hoping to find this case. The 
next step is to filter again using a liming filter (Filter 2 in 
Fig. 14). In this case, the design team is testing the theory 
that close timing between LEAB and data switching on data 
line A causes a narrow pulse, which, when driving the high 
capacitive load of the memory system, causes high ground 
currents. Only the prototype analyzer can find all of the 
occurrences of these conditions and only those that meet the 
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Filter 1 criteria. This consecutive filtering allows engineers 
bo build isolation techniques into their analysis to test their 
theories, rather than having to recapture the data and incur 
the ret rigger and recapture lime penalties. Using the oscillo- 
scope huill into the HP 16500B logic analyzer, they can cap- 
ture with time correlation the lines that are being corrupted 
by the simultaneous switching noise and ground bounce. 
The time correlation allows engineers to retain the state and 
switching context that created the failing conditions. The 
waveform and lister tools merge the analog and code con- 
texts to form a new measurement domain. 

In summary, the prototype analyzer can be used to isolate 
the root cause of this problem much more quickly because it 
has sequential postprocessing filters, allowing analysis of 
entire data records at once. These kinds of problems are the 
cause of many delayed developments in advanced digital 
systems. The prototype analyzer tool is a way to solve them 
more quickly, minimizing time to insight for the design team. 

Conclusion 

Fig. 15 shows the use model for the prototype analyzer, re- 
drawing Fig. 1 to show how tine risk in the concurrent engi- 
neering process can be managed with a single digital analy- 
sis tool platform to unravel the complexities of modem 
digital systems and deliver to design teams the tools and 



Target System 

Fig. 15. Lpdated system design 
process using the prototype 
analyzer, 

processes needed to master the integration phase to com- 
petitive advantage. 
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Prototype Analyzer Architecture 



The HP 16505A architecture allows multiple concurrent views of acquired 
logic analysis data. Markers on all views are correlated. The user only 
needs to place the marker on one view and the markers on the other 
views automatically relocate. Thus a stack anomaly in one view can be 
immediately correlated with the software routine causing the violation 

by Jeffrey E. Roeca 



The HP 16505A prototype analyzer is the next-generation user 
interface for logic analysis. It is an XI 1/Motif application run- 
ning on an HP (WOO Model 712 PA-RISC workstation directly 
tied to the HP 16500 logic analysis mainframe. This system 
is a managed, or closed, system. From boot until power-down 
this system is solely dedicated to extending the prototype 
debug paradigm from the nine-inch touchscreen of die HP 
16500 to a multiple-window, high-resolution interface. 

The design uses the XI 1/Motif graphical user interface ( GUI). 
This was done to accomplish several goals. First, using an 
existing state-of-the-art Gl "I allowed us to foetus on our own 
contributions. Second, with the distributed XI 1 interface, we 
can make the application available over a network to any X- 
compliant computer, including PCs, The software was written 
in C++ for the Model 712 workstation platform. This gave 
our application affordable MIPS, which were needed because 
debugging one-megasample logic analyzer traces across 
hundreds of channels will tax any computer. 

Architecture 

Fig. 1 shows a simple HP 16505A setup. There are three tools 
on the workspace. Two tools are analyzer machines, and 
one tool is a display tool. This simple configuration reveals 
I he essential functions. Tunis can be placed into a data flow 
and run. The analyzers are tools thai probe target hardware. 
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Fig. 1. \ simple III' MiSUSA prototype analyzer setup Available 
tools are selected from the toolbox at left, mid dropped onto the 
workspace, placed into 8 data flow, mid run Here there are three 
tools on the workspace: i wo analyzer machines (M1.M2) and 
one display tool, 



They sample real-world data and the display tools indepen- 
dently view that data 

To deliver this functionality we have partitioned the architec- 
ture into the following blocks: 

• Tools. Tools are the atomic unit of value in the HP 16505A. 
All meaningful user interaction is performed within a tool 
definition. 

• Acquisition Tools. The acquisition tool class is derived from 
the tool class. As such, it plays in the data flow workspace. 
The reason for making this a derived class lies in the way 
we connect or relate acquisition tools to the HP 16500 main- 
frame. 

• Data. All tools export and digest a common unified data 
format. 

• Workspace and Graph. The workspace is the visual pro- 
gramming (il'l. Il allows tools, represented by icons, to be 
connected to a data flow, represented by lines. The graph is 
the ordered list of tools in the flow. 

• Run Management. This is a state machine that pumps data 
through the data flow by executing the graph. 

• General Support. This is basically control or "glue" logic. 

Data Flow 

Let's look at an example data flow through the architeclure. 

When the user powers up the HP 16505A we begin an 
HP-CX* operating system boot procedure. Most of Ihe boot 
code is provided by the Model 712 ROM. but we adjust the 
daemons and hardware con figuration for this application. 
Once the operating system is minimally configured we call 
the session manager routine, which never returns. The ses- 
sion manager handles software updates and spawning of the 
main application. This is also where the workstation is pow- 
ered down. (The Model 712 workstation has a front -panel 
power switch, which forces the HP-CX file system to be 
written to the SCSI drive before actually cutting power. This 
prevents the user from crashing the file system. Cnplugging 
the workstation can be problematic for the file system, how- 
ever, so the session manager has a power-down button to 
remind the user not to simply unplug the product.) 

The real application begins as main c on HP-CX. We begin by 
creating an application context under the X Window System 
with a call to XtVaApplnitializel). The entire application runs as 
an XI I/Molif application. From Ihe (il'l mouse/keyboard 
callbacks through the acquisition control of the HI' 16500, 
all software is run as an XI I application callback 
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The HP 16505A system software offers a handful of sendees 
to tools. These services are collectively gathered beneath a 
structure called the frame. The frame is one of the few glob- 
ally available pointers. Tools can access Uiese system ser- 
vices by referencing frame->service. The frame services are: 
ResourceMgr. Colors, fonts, cursors, path names. 
RunMgr. State machine for stepping the tools through runs. 
FileMgr. Storing and loading of configurations. 
HelpMgr. Help screens. 

GeometryMgr. Pixel drawing management for the workspace, 
Symbols. Definition and display. 
FrameMarkerMgr. Global marker synchronization. 
FrameMessageExchange. Mail service between nodes on the 
graph. 

TbcMgr. Manager of toolbox icons. 
InstrumentMgr. Manages a list of instruments. 
AdminMgr. Networking and other HP-UX management. 
PrintMgr. Print services. 

Next we perform a directory search for instruments and 
tools. Ail tools are compiled into shared libraries. These 
libraries exist beneath a well-known directory. We traverse 
the directories beneath this, searching for valid tools and 
instruments. A valid directory consists of a shared library, a 
resource file, and a pixmap. The load algorithm is genetic and 
does not need to be rewritten when a new tool is created. 
Simply creating a director,' with these three files is sufficient 
for this algorithm to attempt to load. Tools are noted, but are 
loaded only when placed onto the graph. This can be ob- 
served as a slight time delay in the creation Of the first tool 
Of a given class. The benefit of demand loading tools is that 
the memory is kept free for deep trace analysis. 

Unlike tools, instruments are loaded when they are found. 
An instrument is an HP 16500. Within the HP 1G500 there 
can be up to ten modules, but there are not usually so many 
and it is efficient and simple to load them at power-up. 

Next the workspace is created. All of the loaded and noted 
tools are represented by icons in the toolbox. 

Next we start the file system, remote procedure call mecha- 
nism, messaging services, and some other details. Finally, 
we submit all processing to the X Window System by calling 
XtAppMamLoopO. The application goes dormant until either a 
remote command or a GUI event activates a software call- 
back. Even the remote interface becomes an X event as we 
receive remote procedure calls and simply pass them along 
to the X Window System. When XtAppMamLoop returns, the 
HP L6505A returns to the session manager. 

Tool Design 

Toi >ls and their design are a nu\jor factor giving this platform 

room to grow. A tool is a C++ class with a small set of pure 

virtual functions. These functions are: 

getRev. What release of software (e.g.. 1.20)? 

about. Returns general tool information in ASCII format 

save. Saves the tools configuration to a file. 

load. Loads the configuration from a file. 

addToPopup. Call from the workspace frame to add to a menu. 

setName. Call from the workspace to change this tool's name. 

raiseAii. Open up or raise the windows. 

preExecute. Validates the internal state as legal to execute. 

validateConfig. Validates the configuration before loading. 

execute. Receives a new data group, returns a data group. 
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Fig. 2. Tnni ci.-iss hierarchy. 

These tool functions are mostly mundane calls to get, set, 
save, or load static information within the tool definition. All 
real tools must supply these functions, and the system glue is 
written with calls through these functions from tool pointers 
kepi in the graph. 

Only one function deals with the primary objective of a 
tool — passing data — and that is the execute function. This 
function is declared as follows: 

virtual DataGroup * execute {const DataGroup&) 
= 0; 

A tool receives a call and is passed a pointer to the data and 
labels. The tool can then interpret, filter, or create data as 
needed. All that is required is that the tool return a pointer 
to the output data group. This is very simple and powerful. 
Compliance with the execution protocol does not require 
any coupling between tools. 

From this definition all real tools are derived. Fig. 2 shows 
the current tool classes in the IIP 16505A. 

Acquisition Tool Design 

The workspace manages an ordered list of tools. Conse- 
quently, a logic analyzer must be represented as a tool to be 
placed on the workspace. According to HP 16500 legacy, the 
fundamental working unit of a logic analyzer is a machine. 
A single HP L6500 card, or module, can have two machines. 
In the HP 16505A, each of the module machines is repre- 
sented as an individual tool in the toolbox. 'Hie abstract C++ 
class for these machines is called a probed source. Probed 
sources must address multiple complications. One is Com- 
munication with the HP 10500 module. Another is handling a 
workspace presentation t hat represents probed sources as 
Independent tools, while behind the scenes both machines 
of a single IIP 10500 module are joined at the card. Another 
complication is coordinating the remote acquisition of data. 
Fig. 3 presents the acquisition tool hierarchy, showing the 
basic composition of probed sources and their relationship 
to their module (card) and the HP 16500 (enterprise). 

The class that is placed onto the workspace is one of the 
machine classes. Because these classes are derived from the 
probed source class, which is derived from the tool class. 
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Fig. 3. Acquisition tool class hierarchy. The dots and numbers 
are Booch notation for N-to-1 relationsliips. For example, an 
HP 16550 card lias two machines. 

they can be inserted into the workspace. As previously 
stated, a logic analyzer card can have multiple analyzers, or 
machines. Accordingly, each machine has a relationship with 
its parent card class, which is derived from the abstract card 
class. Cards in turn are owned by the acquisition enterprise. 
The enterprise class is derived from the abstract instrument 
class. Within I he instrument class exists the transport 
knowledge, which happens to be SCSI. 

Encapsulating the SCSI transport in the instrument class 
allows us to port the transport layer with a minimal impact 
on I he rest of the software. This was a benefit in the initial 
stages of development when the SCSI interface did not exist 
and we programmed the IIP 16500 over the HP-IB (IEEE 488, 
IEC 625). 

By using ihe existing ASCII programming strings of the HP 
16500 we are able in acquire data in an existing stable plat- 
form. By using the SCSI transport we minimize the latency 
of transfer from the HP 16500 lo the HP 10505A. 

Data 

Data is different for each analyzer card in the HP 16500. 
Historically this slowed development by giving rise to 
custom, hardware-specific algorithms to render that data. 
Behind similar HP 105xx interfaces may be completely dif- 
ferent software. Fig. 4 shows the transform that we apply in 
the HP 16505A prototype analyzer. As data is uploaded from 
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the unique hardware, it is transformed into a common, or 
normalized format. This normalized data is what all tools 
downstream from the analyzer source operate upon (see 
article, page 30). 

Workspace and Graph 

The primary role of the workspace is to construct the data 
flow relationship that is executed during nuts. The data Oow 
is constructed with tools and data. The GUI provides a tool- 
box that contains icons representing all available tools. 
A user drags an icon representing an available tool from the 
toolbox and drops it into the workspace. Data flow is repre- 
sented by lines connecting the icons or tools. Each tool that 
is placed onto the workspace is entered into the graph. The 
graph is an ordered list of containers. A container is a struc- 
ture that holds information about real instantiated tools. Any 
software function can execute the graph, which results in an 
ordered delivery of containers to the requesting function. The 
function can then call the appropriate tool function through 
the container. 

The graph has a simple set of rules determining the order of 
execution of the list of tools: 

• Only tools that are on the workspace are executed. 

• Orphan tools — tools that have no data connections — are 
executed first. 

• Top-level tools such as logic analyzers and oscilloscopes are 
executed next. 

• The graph does not transition from one level to the next 
until all tools at a given level are complete. This ensures 
that any tool that receives data from multiple sources will 
have the data available when the tool is executed, since all 
parent tools must have completed before the tool is called. 

Fig. 5 shows a workspace representation with three analyzer 
machines, two filter tools, a lister, and a waveform tool. Ml 
and M2 are merging their independently acquired dala to- 
gether into a single data group and then passing that merged 
data group through the Filterl tool to the lister. M3 is an 
independent data group that passes through Filter2 into the 
waveform tool, There are highlighted boxes labeled level 1, 
level 2, and level 3. These boxes indicate the order of execu- 
tion of the graph. Level 1 tools are Ihe data sources, or ana- 
lyzer tools. Tins level is executed first. No tool in li'vrl 8 01 
level 3 will execute until all level 1 tools are complete. Once 
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Fig. 4. is different tor each analyzer card in the IIP lfinlH) 
logic analysis system. As data is Uploaded into Ihe HP !6T>05A 
prototype analyzer from the unique hardware, it is transformed 
into a common, ur normalized format. 
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Fig. 5. A workspace representation with three analyzer machines, 
two filler tools, a lisler, and a waveform tool. 
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Fig. 6. Run manager state diagram. 

level 1 is complete then the level 2 tools will execute. No 
tools in level 3 will execute until level 2 is finished. This is a 
general rule: level N-l must finish before level N executes. 

Run Management 

The run manager is the software that pumps data through 
the graph. It is a state machine that executes the graph. 
Remember that executing the graph is an ordered, level-by- 
level event. This ordering allows for all probed sources to be 
configured, stalled, and uploaded as a coordinated group. 

Fig. (i shows the states and their execution cycle, together 
with the entry points into the state machine. The states are: 
PreRunDownload. The IIP 10505A probed source software main- 
tains internal configurations. The (il l modifies the configu- 
ralions and the changes are stored in the IIP 1G505A without 
remotely updating the HP 16500. When Run is pressed, a 
probed source is requested to download to the HP 16500 the 
current HP 16505A probed source configuration. 
PreRunCheck. A given IIP 10500 card may have an illegal set- 
ting that prevents a run from proceeding. This state allows 
the IIP 115500 status to abort a run. 

StartAcquisition. The IIP 10500 is stalled. The current release of 
the IIP 10505A only performs group funs. A group nut is one 
that time-correlates the trigger events from participating 
modules. 

WaitingForCards. The HP 16506A polls the HP 10500 run status 
waiting for the tun completion. 

UploadingNormalizing. Each card is called serially to upload and 
normalize the acquisition data. 

TimeCorrelating. After each card is normalized the system 
acquires the timing correlation values and updates the 
normalized data. 

OataExecution. The normalized data is now passed through the 
graph to the configured tools. Each tool called w ill render 
the data and update its display. 
PostExecution. The IIP 10505A does some cleanup. 

The graph is executed during each state at least once. A given 
state may only choose to communicate with a tool if the tool 
is a probed source. A slate may execute the graph multiple 
times. For example, WaitingForCards is a state that Can lake a 



significant amount of lime, depending upon the repeatability 
and cycle time of the trigger specification. The run manager 
could be stuck in this state forever. The logic within this state 
executes the graph. If the cards are not complete then the nut 
manager sets an X timeout and exits. 

The setting of the X timeout is significant. It is essential thai 
the GUI is allowed to run to service potential stop events. At 
the first release there is no remote control of the HP 10505A, 
and a GUI event on a Stop button is the only way to abort a 
rah. 

Example Control Flow through the Software 

Fig. 7 shows a simplified control flow for acquiring status 
during an acquisition of data. A user has previously pressed 
the Run button, which starts the run manager state machine. 
In this example the run manager has been called (from an X 
timeout ) and is processing the WaitingForCards state. This state, 
like all run manager slates, calls the graph execute function. 
This causes the graph to cycle through all of the tools on the 
workspace. The run manager calls tools that are probed 
sources requesting their status. Now is w here the mapping 
of analyzer machines, or probed sources, to cards becomes 
important. The HP 10500 remote control is ordered by mod- 
ules. Within a module, communication is w ith an analyzer 
machine. The IIP 10505A has requested the run status of an 
executing machine. This request is passed to the parent card 
class. The card knows which IIP 10500 slot to select. The 
Card also knows what messages to apply to obtain the status. 
These ASCII IIP 10500 command strings are then passed to 
the enterprise, or HP 10501)6 class. This is the class that 
inherits from the abstract instrument class. The SCSI trans- 
port sends the ASCII programming instructions down to the 
IIP 10500B and there they are parsed and interpreted 

Fig. S shows a similar simplified block diagram with ihe 
normalized data, tools that are not probed sources, and the 
tool support blocks added. Ignoring the fine details of the 
myriad of support tools, correlated markers, and so on, one 
can obtain a good understanding of the HP 10505A architec- 
ture from this figure. The frame object has a run manager 
object which controls the state machine for acquiring and 
pumping data through the tools. The workspace has an 
ordered lisl of instantiated tools and controls the execution 
order. Tools are either independent lools or probed sources. 
If they are probed sources they communicate through their 
parent card through their instrument through Ihe transport 
layer. Probed sources generate normalized data, and all 
other tools can use, modify, and generate normalized data. 

Examples of Visualization 

The primary value of the HP 10505A lies in its ability to help 
the user visualize data. The architecture was defined to allow 
multiple concurrent views of the acquired data. By slicing and 
dicing data in different ways, fault isolation becomes easier. 
Fig. SI shows an HP 10505A setup demonstrating how visual- 
ization in multiple views promotes rapid time to insight. Soft- 
ware stack corruption is a difficult problem to solve. I sually 
a corrupt stack does not directly reveal itself. More often, 
the product crashes far away from the actual write violation. 
In this example a 08332 microprocessor running software 
has been sampled. This data has been displayed both unfil- 
tered and filtered. The filtered data is shown in ASCII format. 
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Fig. 7. A simplified control flow 
for acquiring stat us during an ac- 
quisition of data The run manager 
slate machine has been called and 
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function, causing the graph In 
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as a chart, ami as a distribution. The filtered dala in chart 
mode shows Ihe stack as a function of time. The filter is a 
simple range between the low and high boundaries of the 
stack. Visually one can see an anomaly in Ihe slack space, 
[n this example Ihe write taking place beneath the G1 marker 
in the Stk vs. Time window is in error. By looking at Ihe ASCII 
listing ofthe unfiltered data in the Raw Trace window we can 
see exactly what software was executing at the time that 
this erroneous write to the slack space took place. 



The HP l(i">or>A allows these mulliple views — Ihe lister and 
the filtered chart — to be displayed concurrently. Within the 
HP llioOii display tools we have correlated markers. The 
default behavior Of a display tool is to track the placement 
of a marker automatically. The user only needs to place the 
marker on the visual stack anomaly, and the lisler automati- 
cally relocates itself to reveal the software routine in viola- 
tion. 
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Fig. 9. An HP MJ505A setup demonstrating Dm diagnosis ofa software slack corruption problem Tbt write taking plat-i- iieneatli tin.* gi 

marker in the sikvs Time window is in error By looking ai the ASCII listing of the unaltered data In the Raw Trace window w* can n xeeUy 
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Determining a Best-Fit Measurement 
Server Implementation for Digital 
Design Team Solutions 

Prototype analyzer customers wanted fast throughput, quick answers, a 
turnkey solution, an affordable base system price, connection to diverse 
open-systems networks and platforms, and interfaces to a wide variety of 
tools. An encapsulated measurement server architecture based on a 
dedicated workstation and a SCSI II interface best fit the requirements. 

by Gregory J. Peters 



Implementing an analysis and display architecture for the 
next generation of HP logic analyzers presented opportunities 
and challenges for the cross-functional design team assigned 
tO the task. Freed from the houndaries of commercial real- 
lime instrument operating systems and needing to offer a 
flexible and high-performance window-based interface, the 
project learn look a long look at both technologies and the 
total envelope of costs before settling on an encapsulated 
measurement server architecture based on an HP 9000 
Series 700 workstation. 

The goal of the HP 1G505A prototype analyzer team was to 
develop a breakthrough analysis and display environment 
for digital design teams involved in the integration and debug 
of prototype systems. The resulting product is a combination 
of the best of traditional instrument and system benefits. 
The turnkey prototyping system provides the performance 
and flexibility demanded by leading-edge digital design teams 
but its low total system cost appeals to the smaller teams as 
well. The tough decisions made very early in the product 
definition phase have paid off. The product meets market 
needs and has a low cost of sales and support envelope. 

Genesis 

The genesis of the prototype analyzer occurred with the 
realization that digital hardware developers, who are tradi- 
tional logic analyzer users, were spending an ever higher 
percentage of time using electronic design automation 
(EDA) tools, such as schematic capture and simulation soft- 
ware packages. The use of workstation or PC-based EDA 
tools came at the expense of time spent in the tab making 
measurements on prototype hardware. 

The workstation or PC was fast becoming home base for 
designers. Traditional test instrumentation was in danger 
of becoming less relevant to the design team, in large part 
because it didn't interface with EDA tools. The question the 
team pondered was how future real-time measurement, sys- 
tems would interface with the designer's workstation home 
base. 

This concern generated an investigation into workstation 
connectivity, and the prototype analyzer project was born. 



The development team at first conducted research with hun- 
dreds of customers worldwide, in different industries and 
with different measurement needs. The results of the inves- 
tigation drove the definition of the prototype analyzer mea- 
surement server implementation. 

Measurement Servers 

Measurement servers are defined as a class of solution that 
combines physical measurements with client/server comput- 
ing. Real-world measurement data is captured, analyzed and 
shared with users and other tools over the network using a 
variety of open-systems standards. 

Measurement servers use widely accepted networking stan- 
dards such as Ethernet, the X Window protocol, and the 
Network File System (NFS) to enable customers to control 
and view measurement instruments anil get easy access to 
measurement data. Standard data formats are used to inter- 
connect the measurement server with other applications. 
Specialized host-based software is not required. Measurement 
servers can provide anywhere, anytime access to prototype 
measurement data via today's ubiquitous networks. 

Client/server computing enables each component of the 
system to specialize in what it can do best. The locations 
and definitions of the interfaces between components are 
determined by the nature of the application and the network 
topology. A well-recognized example of a client/server appli- 
cation can be found in the EI »A industry: a simulation engine 
runs on a large compute server while the simulation inter- 
lace runs on the engineer's desktop. Application developers 
must pick the appropriate points to split apart an application 
to maximize a product's performance and value. 

Measurement server architectures v ary depending on the 
scope of the solution. Some architectures are completers 
encapsulated inside a box, while others are split apart or 
distributed (see Fig. 1 ). Identifying the appropriate point to 
split the application apart is critical. Splitting an application 
at the wrong place can limit response tunes or cause nonde- 
tcrministic behavior. Encapsulating the wrong functionality 
into a system can increase the cost of the system or the cost 
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Fig. 1. Three possible measurement server architectures: distributed, mixed, ami encapsulated. 



of sales without inc reasing revenue. Encapsulating too little 
funrtionality may result in trivial or redundant products. 

The full use of the client/server paradigm is the differentiating 

aspect between traditional Instruments and measurement 

servers. Traditional instruments can also be connected to 
computers via the HP-IB (IKEK 488), but this connection 
requires special interface' and control hardware and soft- 
ware on the host computer. Additional analysis and display 
software is generally custom, arid can be lime-consuming lo 
develop and debug. The localized nature of the HI'-IB limits 
its penetration into open computing environments and the 
need for specialized control and interface software puts 
HI'-IB-controlled instrumentation at a distinct disadvantage 
in Ihe networked design environment. 

Architecture Selection 

To obtain Ihe best price and performance trade-offs, the 
proposed solution must be evaluated closely to determine 
the optimal measurement server architecture. The three 
examples given below highlight some of the issues thai must 
be addressed. The prototype analyzer development leant 
was able to gain valuable experience from reviewing each of 
these product forms. 

An example of a distributed measurement server architecture 
can be found in the HP B3740A software analyzer. This soft- 
ware package provides software developers with a means of 
viewing real-time microprocessor traces referenced lo 
sourer code. The IIP B3740A runs on several workstations 
and on PCs. 



The host-based nature of I his application was derived from a 
need to provide source-viewing functionality to a large num- 
ber of design leant members who timeshare a single real- 
lime instrument (Ihe MP 1R500B logic analysis system). 
In this case, the small amount of data transferred over an 
Ethernet link between Ihe IIP 16500B and the IIP B374GA 
does not impact performance. Performance here is mea- 
sured as update rale. 

As a point application, this product does not requite exten- 
sive support. If Ihe same approach were taken for sev eral 
applications, however, Ihe sales and support burden could 
Until broad market penetration. In particular, maintaining 
host-based software on a platform thai has frequent operating 
system revisions is not only lime-consuming but also results 
in a low return on investment to Ihe development team. 

IIP VEE, a visual programming and test development envi- 
ronment,- best illustrates a mixed measurement server 
archil eel ure. HP VEE runs as a host-based program on PCs 
and works! at ions. This product enables engineers to quickly 
develop lest programs that control a wide variety of Instru- 
ments over the HP-IB on a standard computing platform such 
as a workstation or PC. The key benefil of ibis approach is 
the flexibility afforded both solution providers and end users. 
A choice of supported plal forms means customers can use a 
platform they are familiar with. An open-system development 
environment enables value-added engineering, upon which 
solution providers can build custom applications. 
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A mixed measurement server archil eel me lias drawbacks, 
however. Maintaining a reliable interface between the host- 
based software and I he measurement instruments through 
operating system revisions or changes in network protocols 
can be challenging. Setup and maintenance of a distributed 
system require significantly more effort than a turnkey 
instrument. A dedicated Ethernet network can impose band- 
width barriers that severely limit measurement throughput. 

The HP lfioOOB logic analysis system with an HP 16500H,L 
interface module is an example of an encapsulated measure- 
ment server. This system can provide both local and remote 
control and viewing via the X Windows protocol. The ton- 
key nature of this product makes installation and setup sim- 
ple. Since all dala processing lakes place in the instrument, 
only X Window calls are transmitted over the Ethernet This 
helps keep the update rate fas! over most network lopolo- 
gies. 

While the support burden of an encapsulated measurement 
server is low. it comes at a price. User-defined measurement 
sequences and extended data analysis and reporting are not 
provided. Customers must make a connection to the HP 
16500B and import data and screen images into a general- 
purpose computer to perform these tasks. 

Considerations such as customer expertise in open systems, 
support costs, and the use model for the product musl all be 
factored in when choosing an architecture for a measurement 
system. Trade-offs must be made lo Til the needs of the mar- 
ket and target customer. Table I outlines the advantages and 
disadvantages of the three measurement server architectural 
approaches. 

Customer Requirements 

The workstation connectivity investigation generated an 
extensive set of customer requirements. These inputs 
spanned the entire realm of product definition, from tech- 
nology needs through user disciplines and measurement 
tasks. The investigation revealed: 

Prototype measurements are essential for hardware/soft- 
ware integration and product verification. 
There is a wide variety of use models, from the benchtop 
standalone user lo completely networked control and 
viewing of measurements from a remote site. 
An analyzer might see single-person use or shared use by 
teams of as many as 50 engineers. 

There is a strong desire for a turnkey system, not a collection 
of components that must he integrated by the customer. 
Equipment setup time must be a minimum Customers want 
to be able to make a connection to the prototype and make 
measurements as soon as possible. 

There is a broad diversity of measurement needs, from signal 
integrity to software, and across a variety of probed points, 
from serial buses to RISC processors. 
Surprisingly, we found the potential to address a broader 
group of customers than envisioned before the investiga- 
tion, including software developers, who traditionally 
av oided the lab and used host-based software development 
tools. 

We heard a strong request for snappy displays and quick 
measurement results (facilitation of the debug loop 
explained in the article on page 6). 



Table I 

Measurement Server Architectures 
Advantages 

Distributed 

• Fastest leverage of links lo oilier host-based applica- 
tions. 

• Most efficient at using customer's available computing 
power (MIPS). Takes advantage of idle MIPS on 
customer's host computer. 

• Low cost of goods sold (software only). 

Mixed 

• Provides best mix of flexibility and power for custom 
system development. 

• Besi for integral ing different measurement systems. 

• Deterministic performance can be achieved ov er a 
dedicated network (HP-IB). 

Encapsulated 

• Turnkey solution (ready lo run). 

• Very high measurement throughput. 

• Deterministic performance. 

• Low cost of sales. 

• Low cost of support. 

• Low R&D resources required to support and enhance 
the system. 

Disadvantages 

Distributed 

• taw measurement throughput 

■ Noiideieniiinislic performance (Ethernet )■ 

• Requires coin inning R&D effort to mainiain support on 
new operating system revisions. 

• Requires extensive and time-consuming QA on 
supported host platforms. 

• Requires some customer operating system and I/O 
knowledge. 

i Higher support costs than encapsulated solution. 
Mixed 

• Requires special dedicated network hardware and soft- 
ware. 

• Requires customer operating system, I/O, and networking 
knowledge. 

• Throughput can be limited (depending on the perfor- 
mance of the dedicated network). 

• Requires continuing R&D effort to maintain support on 
new operating system revisions. 

• Higher support costs than encapsulated solution. 

Encapsulated 

• High cos! of goods sold. 

• Fixed functionality. 

• Low efficiency of using customer's available MIPS. 

• Requires some networking knowledge. 

• The solution must interface with a wide variety of design 
tool chains, consisting of EDA software programs, test 
development programs, and others. 

• There is a desire for connection to diverse open-systems 
networks consisting of nearly every possible combination of 
computer hardware and operating system software on the 
market. 
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The base system must be affordable to reach most users 
and scalable to cover both performance and mainstream 
users. 

The Ethernet protocol was in use at most customer sites. 

Taken together, these inputs overwhelmed the project team. 
Scaling the task to available time and resources became a 
critical project goal. Reducing the dimensionality required 
of the architecture would be the key to delivering an on-time 
product that met key user needs. 
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Demographic Factors 

Digital design teams of all sizes are found in every indus- 
trialized country. Design teams as small as two engineers 
expressed many of the desires listed above. Because of the 
broad demographics of digital design teams, a key challenge 
was offering a low cost of sales and support product struc- 
lure to fit a sales channel that could reach these customers. 

A complex product structure greatly increases the cost of 
sales and support. A high cost of sales makes broad product 
adoption difficult. This is because complex product struc- 
tures typically demand a specialized sales and support orga- 
nization, which in turn limits coverage both geographically 
and at smaller accounts. Product specialists are expensive 
because of their training and expert knowledge, but also 
because it is difficult for diem to cover the same geographic 
area as thoroughly as a group of generalists who make daily 
contact with a wide variety of customers, and who sell a 
wide variety of products. 

Product generalists are far more likely to make contact with 
small customers. These customers are less inclined to pur- 
chase a system they view its so complex that a specialist is 
required to sell and support it. Creating a product that de- 
mands product expertise and specialization of a sales force 
directly Contradicts the fact that design teams of all sizes 
and budgets have many of the needs listed above. 

The resolution of this issue became a focal point of the 
prototype analyzer product structure. The outcome of the 
measurement server architecture decision would be the 
major contributor to the cost of sales. Reducing the dimen- 
sionality of the product would help lower overall costs and 
allow the product to be sold and supported by generalists, 
not specialists. 

Issues 

The four issues that most affected the choice of measure- 
ment server architecture were: 
Fast throughput and quick answers 
A desire For a turnkey solution 
An affordable base system price 
Connection to diverse open-systems networks and 
platforms and interfaces to a wide variety of tools. 

The additional requirement that was used as a stalling point 
for the design was that the product must work with existing 
HP L6500B systems and measurement modules. The design 
team was to create a product that added functionality to the 
IIP 16600B system but did not require customers to make a 
significant new investment in real-time acquisition hardware. 

Work on the core software architccltuv began independently 
of the measurement server decision. The four issues were 
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Fig. 2. HP 18505A prototype analyzer measurement server 
implementation. 

used as a basis for discussion about Lite pros and cons of 
each measurement server architecture. In the end, an encap- 
sulated architecture was chosen, as shown in Fig. 2. 

Throughput 

Throughput was a key element of the prototype analyzer 
design. A customer set a benchmark for the design team by 
stating the expectation that a full screen of HP 16550A data 
should be refreshed once per second. This became known 
as the "one update per second" goal and was used as the de 
facto throughput benchmark. 

Table II out lines the amount of data that some HP HiollOB 
logic analysis system measurement modules capture in one 
acquisition. The italic numbers indicate common configura- 
tions. These con figural ions were used in ad hoc tests by 
R&D to evaluate the update rate as the software architecture 
progressed, 

A single acquisition covering several microseconds could 
generate as much as 30M bytes of data. Sending this amount 
of data over a customer's local area network would be im- 
practical and would cause severe network performance 
problems. It was obvious that some sort of dedicated net- 
work would be required to move data quickly from the HP 
I6500B system to a workstation or PC for data normaliza- 
tion and display. 

The real-time nature of the system implied a robust and 
deterministic interface. Handling real-time I/O across open 
netw orks without the benefit of a well-defined protocol is 
difficult, and would require special drivers on both ends of 
the network. Polling real-time code across platforms would 
add complexity to the design. 



© Copr. 1949-1998 Hewlett-Packard Co. 



June 1096 I lewtett Packard Journal 25 



Table II 

Typical Measurement Data Sets 
HP 16500 

Measurement Module 1 Module 2 Modules 3 Modules 

HP 16550A 500-MHz 55K 1 1 OK N/A 

Timing. 100-MHz State. bytes bytes 
4K Depth. 
100 Channels 

HP 16555A 500-MHz 8M 16M 2W 

Timing. 1 10-MHz State, bytes bytes bytes 
1 M Depth, 64 Channels 

IIP 16532 A l-GSa/s HSK 32K 48K 

Digitizing Oscillo- bytes bytes bytes 

scope, 8K Deep, 
'1 Channels 

HP 16517A/18A 128K 25GK 384K 

4-GSa/s Timing. bytes bytes bytes 

1-GSa/s State. 64K 
Deep, 16 Channels 

Leveraging analysis done by HP Laboratories and other divi- 
sions/' the design team was quickly able in evaluate interface 
performance characteristics. Table III provides a comparison 
of different interfaces and the estimated throughput of each. 
Data handling in the HP 16500B and normalization time in 
the HP 10505A is not included in these figures. 



Table III 

Interface Speeds and Estimated Throughputs 
for 11 OK Bytes of Data 









Transfer 


Transfer 




Maximum 


Typical 


Time for 


Time for 




Transfer 


Transfer 


11 OK Bytes 


24M Bytes 


Interface 


Rate 


Rate 


of Data 


of Data 


HP-IB 


1 Mbyte/s 


240 kbytes/s 


0.47 s 


100.4 s 


R\ hernel 


1 Mbyte/s 


300 kbyt es/s 


0.38 s 


80.7 s 


scsin 


6 Mbytes/s 


1.5 Mbytes/s 


0,07 s 


15.27 s 



Although all three interfaces perforin the 1 lOK-byte transfer 
in less lhan 0.5 second. Ihe SCSI II interface offered a sub- 
stantial improvement in performance, which would be 
needed when transferring the 30M-hyte Hies found in high- 
end HP logic analysis configurations. 

SCSI II was not the first choice of the design team. The HP 
16500B already had HP-IB and Ethernet ports. Adding a 
SCSI poii would lake more lime and resources. Some team 
members argued that HP-IB performance could be im- 
proved. However, the HP-IB interface would then require a 
corresponding comiection on the other end. Since work- 
slaiions and PCs don't come standard with HP-IB interfaces, 
the use of this port would require special hardware for the 
host computer. No one relished the task of designing a 
computer-based HP-IB card or evaluating the commercially 
available cards. 

Ethernet was a clear winner from a user perspective and an 
Ethernet port was available on Ihe HP 16500B. The Iwo 
strikes against Ethernet were its performance compared to 



SCSI II and ils inherent nondetcnuinistic behavior, a resuli 
of the collision detection and retransmission scheme used. 

In Ihe end, the SCSI II porl won out. In retrospect, the use of 
the fastest interface available was an excellent choice, since 
IIP 16500B data sets continue to grow in size and customer 
throughput expectations constantly increase. 

As Ihe design learn developed the software architecture, ii 
became apparel il thai there were many areas where code 
optimization could improve throughput. A problem with 
software optimization is that il is often dependent on the 
architecture of the underlying hardware. All hough the team 
was using the HP 9000 Series 700 workstation as a develop- 
ment station, a platform choice had not yet been made. One 
factor thai swayed the development team in favor of an en- 
capsulated measurement server was their feeling thai signif- 
icant improvements to performance could be obtained by 
liming the soli ware architecture to one computer architec- 
ture. This insighl proved fortuitous because Ihe R&D team 
got the chance to optimize Ihe architecture and gain a lOx 
performance improvement when Ihe coding was complete. 

The decision to use SCSI II meant that a distributed mea- 
surement server architecture would not be feasible, since 
SCSI is not a network protocol. 

Turnkey System 

With the interface issue settled, the design team began in- 
vestigating dedicated controllers. Both workstations and 
PCs were evaluated. Each platform had advantages and dis- 
advantages, as outlined in Table IV. 



Table IV 
Controller Comparison 

Advantages 

Workstations 

Highest single-processor performance available 

Standard SCSI interface 

Good networking 

Good development environment 

Can act as X client or server 

Excellent graphics support 

PCs 

Good performance 

Generally lower cost than workstation 
Excellent development enviromnenl 
Customers familiar with Microsoft Windows® 
SCSI interfaces available 

Disadvantages 

Workstations 

Higher cost than PCs 

Many customers no) familiar with HP-UX* operating 
system 

Potential for file system corruption 
Requires more base system memory 

PCs 

X client software not readily available 
Acceptable but not robust networking 
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An important factor in the decision between a workstation 
and a PC was the ability of a workstation to operate as both 
an X client and an X server. Since customers demand both 
local and remote viewing and control of the prototype ana- 
lyzer. X Windows was a necessity. In general. PC-based o|H?r- 
ating systems did not support this function or handled it as a 
special case. 

However, a problem with the choice of a workstation was 
the HP-l'X operating system. Many customers were not 
familiar with HP-L'X and did not want to leam it- Seeing an 
HP I FX prompt on the screen would also create problems for 
HP's general-purpose sales channel, who were generally 
unfamiliar with the I 'NIX ' operating system. 

The team decided to create a complete turnkey system on 
top of the operating system, This meant that the system 
could not be used to run other HP-I X applications or as a 
general-purpose computer. While the implementation of this 
policy was not technically difficult, explaining the concept 
took considerable effort. The team found that since there 
were many existing models of mixed measurement server 
systems, the natural conclusion was that the prototype ana- 
lyzer would also be open for customer development. The 
level of communication required to explain that the proto- 
type analyzer would he turnkey was much higher than antic- 
ipated. In the end, the team found that demonstration was 
by far the most effective way of conuiutnicating the product's 
struct lire and its advantages. 

An added benefit of offering a turnkey system was that the 
team did not have to worry about operating system revisions. 
Maintaining tin open system would require the team to put 
ongoing effort into Supporting three operating system revi- 
sions: the last, the current, and the future. 

The prototype analyzer is huilt upon only one operating sys- 
tem revision. The entire system will be revised only when 
customer needs change and substantial new functionality is 
required. This frees the design team from chasing operating 
system revision-related product defects. 

Meet ing Price Goals 

Research indicated that while customers wanted a powerful 
analysis and display environment. I heir perceptions of price 
were influenced by the availability of PC and workstation- 
based data analysis packages thai sold in the I'.S. $10(1(1 to 
$. r >0(!() range. ( 'uslomers also viewed the prototype analyzer 
as a kind of operating system. ( tperating systems aren't val- 
ued as highly as the applications that run on them 

This data implied that the total system price would need to 
be in the range of U.S. $5001 1. The design team had two areas 
where costs could be lowered. The workstation would rep- 
resent a large portion of the prototype analyzer material 
cost. Selling and support expenses also contribute to the 
total system cost. 

Concurrent with the prototype analyzer development, Ill's 
Workstation (iroup was designing the IIP !I(M)0 Model 7VJ. 
loW-COSl workstation. A review of the workstation's price 
and performance specifications indicated that it would be an 
ideal fil as an encapsulated measurement server. 

The base system would consist of a (iO-MHz CPI I, 32M bytes 
of HAM and a 525-Mhyte hard drive The system would be 



shipped from HP's workstation manufacturing operation to 
the Colorado Springs Division, where a new operating system 
and the application code would be loaded and tested. The 
completed product would be shipped to customers front 
Colorado Springs as a turnkey system. Mininuzing the extra 
handling helped keep direct manufacturing expenses low. As 
with any new product, initial inventory was difficult to esti- 
mate because there was no order history. However, the abil- 
ity to order and receive semiconfigured systems with fairly 
short lead times helped maintain a low inventory and thus 
contributed to a low manufacturing cost. 

Cost of sales is defined here as the effort put into customer 
contact, demonstration, and objection handling during the 
sales process. Although precise numbers on these efforts 
are not available, the design team had sufficient practical 
experience to know what factors contributed to a complex 
product and a higher cost of sales. 

Traditional instruments generally have a low cost of sales 
because they can be easily explained, demonstrated, and left 
with the customer for an extended evaluation. The instru- 
ment model was used as a goal for prototype analyzer struc- 
ture, connection, and demonstration. 

A learning products engineer was assigned to evaluate barri- 
ers to installation and first measurement. Two goals were 
adopted. The first was that customers should be able to get 
the system naming from a shipping box in less than one hour. 
This was accomplished by examining in detail the steps a 
customer would take getting from the shipping box to 
power-up. 

A second goal of getting from turning on the power to a 
measurement in less than 1"> minutes resulted in significant 
changes to the initial user interface design. The initial inter- 
face used the standard window bar to access instrument, 
analysis, anil display tools. After several days of usability 
testing at a customer site, the learning products engineer 
mocked up a toolbox on the left side of the workspace using 
masking tape on I he monitor. The toolbox contained all avail 
able tools. These tools could be dragged and dropped onto 
the workspace (see Fig. •'!) and would automatically connect 
themselves. 

The efforts put into these goals paid off Both Sales engineers 
and customers found the product easy to set up and run. 
The toolbox proved to be a big hit (luting customer demon- 
strations and added significantly to the case of use of the 
product. 

Products with a substantial software content present sup- 
port problems. The EDA industry generally addresses this 
issue with software maintenance or support contrai ls, 
which provide the customer with software updates and 
defect fixes over a specified period of time. Software main- 
tenance contracts are generally priced at a percentage of the 
total system software cost. 

The prototype analyzer leam wanted to hold to the instru- 
ment model. Most instruments do not have soft ware mainte- 
nance contracts. Instead, software upgrades and defect 
fixes are usually distributed through an ad hoe process of 
sales and system engineers personally distributing flexible 
disks or occasional mailers to customers who have expressed 
an Interest in future software upgrades. 
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The prototype analyzer team decided io implement a soft- 
ware notification process. This process would reduce the 
burden on the HP sales or system engineer of disi ributing 
new software and deled fixes. Defects and minor revisions 
would be distributed free of charge. Customers would re- 
ceive notification of the availability of major revisions and 
related new products. 

The difficulty with this approach lay in the need for many 
new processes within HP. These included development of a 
call-handling center to interface with customers and get 
their names and shipping addresses for the free updates. 
Process improvements are ongoing, but customers have 
indicated their satisfaction with the approach. 

Standard Interfaces 

Somebody once commented that the great thing about stan- 
dards is that there are so many to choose from. The proto- 
type analyzer design team faced a bewildering array of net- 
working, data, and tool chain standards. Narrowing the 
choices down to just a few supported standards would be 
required to meet the project schedule. 

Networking standards were quickly defined as a result of 
the decision to go with the encapsulated architecture. This 
choice necessitated the use of the X Window protocol to 
support local and remote control and FTP/NFS to get data in 
and out of the system. Ethernet was the natural choice for a 



Fig. 3. Tools can be dragged from 
the toolbox at the left side of the 
display and dropped onto the 
workspace of the HI' KioOBA 
prototype analyzer. They connect 
themselves automatically. 

network connection. Fortunately all of the networking hard- 
ware and software was already present in the HP Series 712 
workstation and only needed to be augmented with a graphi- 
cal user interface. 

Early prototype analyzer users found that the networking 
was sufficient but not ideal. In particular, customers asked 
for die ability to call up remote X Windows applications 
onto the prototype analyzer's local display. This feature was 
useful because customers could access a remote application 
such as a schematic or text editor from the lab bench. This 
capability was added in a subsequent release of the product 

Interfaces to hardware and software tool chains continue to 
evolve. The encapsulated measurement server approach en- 
ables the design team to maintain control over the type and 
manner of data exchanged with other design tools. Having 
control over this process provides additional robustness and 
stability which is critical to maintaining the low cost of sales 
discussed above. 

The Results 

The HP 16505A prototype analyzer has met its price mid 
performance goals. The only true measure of a product's 
contribution, however, is customer acceptance. A wide 
range of customers, including all major computer manufac- 
turers, have purchased prototype analyzers to aid in the 
development of their high-performance digital systems. 
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Measurement throughput continues to improve as the design 
team gains knowledge about the cause of performance bottle- 
necks. The ability to focus on a single platform and the sim- 
ple software update process afforded by the encapsulated 
nature of the prototype analyzer make it easy for the design 
team to develop and distribute new software that contains 
performance improvements. 

Adherence to network standards such as FTP. NT'S, and the 
X Window System lias lowered the support burden. How- 
ever, the diversity of customer networking schemes does 
create a demand for factory-based network troubleshooting 
expertise. The design team will continue to apply best net- 
working practices to the system in an effort to reduce the 
occurrence of network setup problems. 1 "sability testing will 
be used to gain insight into networking problems. 

The ability of the architecture to support additional function- 
ality makes it a cornerstone of HP's real-time measurement 
solution for digital design teams. The reduced cost of incre- 
mental development and the low cost of sales and support 
are important product attributes that outweigh the higher 
cost of goods sold compared to host-based architectures. 

Conclusions 

The development of the HP 16506A prototype analyzer pre- 
sented unique challenges to the project team. The encapsu- 
lated measurement server approach taken by the team 
meant there were no guideposts to follow. The success of 
the project was in doubt until the product was introduced. 

The decisions described in this article may appear obvious 
in hindsight They were not. The design team wrestled with 
the pros and cons of the measurement server architecture 
decision throughout the product development cycle. As new 
data became available, the team eventually rallied around 
the encapsulated approach. As with any new endeavor, at 
the time the decisions must be made, there are no right 
answers, only informed judgments. 

The design team learned several lessons during the develop- 
ment process. One clear lesson was to focus on solving cus- 
tomer needs. Issues such as internal architecture and form 
factor are important, but clearly secondary to the problems 
the product is trying to solve. An important market research 



lesson the team learned is to encourage customers to de- 
scribe their problems, not their thoughts on instrument 
architecture. 
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A Normalized Data Library for 
Prototype Analysis 

The goal was that each analysis and display tool to be included in the 
prototype analyzer should be designed and written only once. Therefore, 
the data library is designed to normalize the variety of basic logic analyzer 
data types and the variety of postacquisition data types generated by 
various analysis tools and to present this data to other analysis and 
display tools in a standard format. 

by Mark P. Schnaible 



Early III the design ol" the IIP 16505A prototype analyzer we 
realized we needed a new library for storing and retrieving 
logic analyzer data if we were going to meet our project 
goals. We needed to duplicate the results of hundreds of 
soflware engineer-years of elToil in the III' l<>r>(IUA/H logic- 
analysis system and measurement modules. We also had to 
lay the groundwork to meet the requirements of our proto- 
type analyzer vision. 

Understandably, we did not want to allocate enough people 
to meet the first challenge for the duration of our relatively 
short schedule. However, looking at where the original lime 
was spent led to some insights. In the original IIP Iti">(l()A/B 
system, effort had to be duplicated for each logic analyzer 
plug-in card introduced. That is, for each card, the lister, 
waveform, chart, and other soflware modules needed to be 
rewritten; Some code leveraging look place, but we did not 
come close to complete code reuse. The different ways in 
which the analyzer cards present dala to the software (largely 
because of differing memory layouts) had much to do with 
this lack of reuse. Qui of this observation came the design 
goal that each analysis and display tool to he included in the 
prototype analyzer should be designed and written only once. 
This meant (hat our library needed to handle the variety of 
basic logic analyzer data types as well as accommodate the 
variety of postacquisition data types thai our envisioned 
analysis tools would generate, and present this data to Other 
analysis and display tools in a normalized formal . Fig. 1 
shows the reduction in the dimensions of the coding effort 
we hoped to attain because of this library. It also shows thai 
we would have automatic commonality of feature sets 
across acquisition modules. Previously, some features for a 
new logic analyzer card were not present at the initial release 
of that card. 

Several other design goals emerged that would allow us to 
meet our challenges: 

Retrieval time for analysis and display tools to access I he 
data should be minimized. In the HP lfi5()0A/B environment, 
the acquired data is examined in typic ally one display per 
acquisition. In the prototype analyzer environment, the goal 
was to encourage dala exploration and to view and analyze 
acquisitions with sev eral tools. We wanted to permit users 



to examine data simultaneously with the same view in dif- 
ferent locations and with different views in the same loca- 
tion. These use models led to multiple accesses of the same 
data, in contrast with the IIP 16500A7B model of a single 
view of dala in a single location. Fig. 2 shows the equivalent 
prototype <uialyzer graph of an HP 16500A/B use model wliile 
Fig. 3 shows a prototype analyzer graph with the multiple- 
view, multiple-location use model. 
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Fig. 1. 00 In the HP 18800A/B logic analysis system coding model, 
tool software had In be rewritten for each plug-in card, (b) In the 
HP IGuOfiA prototype analyzer coding model, data is normalized 
immediately after acquisition and is available to all tools in a stan- 
dard format. Thus, the tools had to be coded only once. 
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Fig. 2. Prototype analyzer graph 
uf an III' 1O5O0A/I3 logic analysis 
system single-view, single-location 
use model. 



Storage space for acquired dala should be minimized. Given 
ihe potential size of some logic analyzer acquisitions 
( >40M bytes), undue expansion of the data was unaccept- 
able. As always, however, (here exists t lit* irade-off between 
ininiiuized retrieval time and minimized storage space. 
The storage mechanisms used by the library should be com- 
pletely decoupled from application or client modules. That 
is, changing the way data is stored should not affect any 
lines of client code. Examples of client code include the 
tools that, analyze and display the acquisition data such as 
the lister, waveform, chart, distribution, and pattern filter 
tools. 

The interface to the library should be a "natural" C++-style 
application programming interface. No new style of pro- 
gramming should be introduced that would be different 
front normal C+ + syntax. 



The library should provide a layer of memory management 
over the acquired data. Again, the possibility of very large 
data sets makes it vitally important not to leak these huge 
memory chunks or provide stale pointers to nonexistent 
data. This goal is made more difficult by the potential com- 
plexity of graphs possible in the prototype analyzer. Fig. 3 
shows that there may be many analysis and display tools 
examining and viewing the data simultaneously. All of these 
references to the data must be handled properly to prevent 
large memory leaks. 

Finally, time correlation between different sets of data or 
analyzer acquisitions must be possible. This requirement 
makes il possible lot users In examine their systems on 
several different hierarchical levels concurrently, from look- 
ing at Ihe analog nature Of a ground pin bouncing to looking 
at Ihe high-level source code executing at that moment in 
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time. Time correlation of measurements also makes it feasi- 
ble to plot one derived measurement against another derived 
measurement. Previously nonobvious relationships between 
variables may appear as a result of these charts. Simply 
having the ability to move markers in one view of an acqui- 
sition and watch that location automatically tracked in a 
different view of the same acquisition is another benefit of 
time correlation. 

Stalling with this list of requirements, we searched for any 
existing libraries that would meet our needs. We examined 
three I II' internal libraries and one public-domain library. 
None of these met all of our requirements; Among the rea- 
sons we rejected them were data set size limitations, 
non-C++ APIs, file-based memory storage, inefficient stor- 
age models, inability to handle the variety of data types, and 
mismatches between application models. 

Data Sets and Data Groups 

The visual programming user interface of the HP 1G505A 
prototype analyzer presents users with a left-to-right flow of 
data from sources to displays. Lines between the icons rep- 
resent this flow. The first thing to decide was exactly what 
kind of objects move from icon to icon. 

One of the first things users do in the HP 16500A/B environ- 
ment is to define what the analyzer probes are connected to. 
This seemed like a natural place to start our definition of the 
normalized data library. A label entry represents one or 
more probes defining a logical value. Typical examples are 
the logic analyzer probes connected to an address, tlata, or 
status bus of a microprocessor or an oscilloscope probe 
connected to V cc , V^, or a clock signal. The label entry has a 
name, polymorphic ordinate data, attributes, and perhaps a 
database of value-to-symbol mappings associated with it. 
Fig. 4 shows the class diagram of a label entry using the 
Booch notation. 1 A logic analyzer or oscilloscope commonly 
probes several of these label entries. 

If we collect all label entries that share exactly the same 
sampling information, we have a data set. All of the label 
entries from a single logic analyzer acquisition share the 
same sampling information, so they can be collected into 
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Fig. 4. Class diagram of the label entry dass using Buoch noialion. 1 

a data set. Likewise, all of the label entries from a single 
oscilloscope acquisition share the same sampling informa- 
tion. The data set contains a pointer to some polymorphic- 
data representing I his sampling or x-axis information. We 
call this the abscissa data. The actual abscissa data object 
varies with the type of acquisition. The data set also contains 
time correlation information indicating which other data 
sets a particular data set can correlate with and indicating 
their relative trigger times. Another form of information 
contained in a data set is called tags. Tags represent the 
availability of each sample row in a data set. Tools such as 
the pattern filter or the sequencing filter can remove lines 
from a data set based on some pattern of data or a sequence 
of data. The memory for these lines is not deleted; the lines 
are simply marked as not available by these tools. 

When we collect one or more data sets for input to a tool, 
we have a data group. Data groups are the objects that "go 
along the wires" of the visual programming graph. A data 
group is simply a list of data sets and some information indi- 
cating I he nature of correlation among the data sets. A data 
group may contain data sets that have no correlation, time 
correlation, state con-elation, or both time and state correla- 
tion. Each tool can indicate to the system what kind of cor- 
relation it requires incoming daia sets lo have. Inputs that 
do not match this criterion cause a warning message to be 
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Fig. 5. Class diagram for data sets 
and data groups. 
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Fig. 6. < 'lass hierarchy for abscissa data. 

shown on the display. Fig. 5 shows the class diagram for 
data sets and data groups. 

Abscissa Data 

As mentioned above, the x-axis information (the abscissa 
data object contained within each data set) is a polymorphic 
type dependent on the type of acquisition or measurement 
of the data. Fig. 6 shows the class hierarchy of this informa- 
tion. The abscissa data base class represents a simple num- 
bered sequence of states with one of those states being the 
trigger state. This concrete base class is the type used for 
generic logic analyzer state clocked acquisitions with no time 
information, that is. no time tags. Objects of type periodic 
are used for logic analyzer timing acquisitions as well as 
oscilloscope acquisitions. This class stores information 
about the sample period and exact time at trigger. The limr 
tags class is used for logic analyzer state acquisitions with 
time tagging turned on. These tags indicate die exact time 
for each sample, which may or may not be periodic. This 
class is also used for calculated data sets derived from logic 
analyzer acquisitions. For instance, a series of setup and 
hold calculations derived from a timing acquisition will have 
a time tag for each pair of setup and hold values. We can 
save considerable space with this technique because the 
setup and hold limes are sparse compared to the sample 
density of Ihe original acquisition. 

Ordinate Data 

The probed data or calculated data contained in the label 
entries is also a polymorphic object. The base class of this 
hierarchy is an abstract base class called ordinate data 
which defines the interface for classes derived from ordinate 
data Fig. 7 shows the class hierarchy rooted with ordinate 
data. Classes derived from ordinate data are analog, stales, 
glitch, and State OQUnt, Other classes can be added to this 
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hierarchy as needed. The analog class contains a polymor- 
phic pointer to the quantized samples and an object specify- 
ing how to convert these quantized values to floating-point 
values. In the case of an oscillosc ope acquisition, this 
header contains the formula to convert from quantized sam- 
ples to voltage. The states class contains a pointer to some 
polymorphic data representing the binary values acquired at 
the logic analyzer probes. The glitch class contains the same 
information as the states class as well as a parallel data ob- 
ject indicating the presence of glitches for each sample. The 
HP 16550A logic analyzer card is capable of acquiring this 
type of data. The state count class holds the data represent- 
ing the number of states that transpired between acquired or 
store-qualified states. The trigger systems of HP logic ana- 
lyzers allow users to specify which states to store out of all 
the states the logic analyzer sees based on some sequence of 
events. The state count object holds values that represent 
the number of states tiiat were not stored. 

Analyzer Memory Layout 

Our definition of a label entry shows that the data for each 
label entry is stored with that label and the data for no other 
label entry is stored with that label. This contrasts with the 
HP 16500A/B series of logic analyzer cards in which all of the 
acquisition data is stored in one block of RAM. Each time 
the data for a particular label needs to be retrieved, the bits 
must be extracted from this block and packed into a value 
representing a sample. As Figs. 8 to 10 show, the format of 
these blocks of memory differs from analyzer to analyzer. 2 3 
The data formats in the acquisition cards are designed to be 
optimally space-efficient. There is a one-to-one mapping 
between bits of memory and probe tips so no memory waste 
occurs. There are two downsides to this design choice: 
( 1 1 lime must be spent every time a sample needs to be ex- 
tracted from this block of memory and (2) the memory lay- 
outs are different for each analyzer. For the multiple-view, 
multiple-location use model of the prototype analyzer, access 
time for each sample of data is critical. For code reuse rea- 
sons, we need to hide the memory layouts from client code. 
Since these acquisition cards were already in production, we 
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Fig. 9. HP 16550A acquired data 
format (one-card analyzer only). 




had little motivation to alter the way they presented data to 
the prototype analyzer. We wauled lo minimize the software 
investment in these finished products. 

Format Specifications for Labels 

Fig. 11 shows a partial format specification for the Intel P54C 
microprocessor. Customers use litis dialog to specify which 
pins on various pods of logic analyzer probes are connected 
to different labels. Some labels, such as for an address bus or 
a data bus, tend to be probed with contiguous probe tips. 
However, other labels can be probed with discontinuous pins 
from different pods. The exception label (Excptn) in Fig. 11 is 
an example of this in I he P54C specification. Depending on 
the complexity of the formal specification, the extraction 
time for these labels can vary greatly. Even for contiguous 
labels with widths of 32 or Hi bits such as address or data, 
considerable time can be spent extracting these values from 
lite monolithic block of memory. 

For the normalized data library, we decided to extract Hie 
data for each label once for each acquisition and store it in 
its own chunk of memory. Label entries whose bit widths 
match the native machine data type widths (8, 1(5, or 32 bits ) 
are extracted and stored as arrays of C'++-lype chars, shorts, 
or ints. Once these samples have been extracted or normal- 
ized) subsequent retrievals are simply array lookups. All 
labels that have non-native widths are combined into a block 
of bytes. Before the values are inserted into this block, how- 
ever, any discontinuity in the ordering of the bits is removed 
to speed later retrievals. Some space inefficiency can result 
from this technique. The total possible bit wastage is: 
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We make this trade-off to provide faster access times to the 
data. Data drivers for each logic analyzer module supported 
are responsible for normalizing the data. These drivers can 
be arbitrary about choosing data types because they know 
the memory layouts of the cards and the specific widths of 
labels. Fig. 12 shows the class diagram of the ordinate data 
types with the various integral data types. 

Accessing the Data 

Once we have stored the data in a normalized format, we 
need methods 1.0 access the data. A study or existing code 
and an analysis of how future tools might need to access the 
data showed that retrieval tended to be very sequential in 
nature. If we picture an acquisition as a matrix of data, with 
rows representing samples or time and columns representing 
the various labels, two retrieval styles emerge: row major 
and column major. Tools that use the row major style want 
to examine all of the labels for a certain sample before they 
proceed to the next sample. The lister, pattern filter, and 
sequencing filler use litis style. Tools that use the column 
major style look at all samples of a particular label or column 
before they look at the next label. Waveform drawing, chart- 
ing, and histogramming tools access the data this way. 

A programming idiom that supports this sequential nature of 
accessing data is called an iterator: 1 We defined classes for 
iterating over data contained in the abscissa data class hier- 
archy as well as data contained in the ordinate data class 
hierarchy. Fig. 13 shows the abseissa-ilor class hierarchy 
and Fig. 14 shows the ordinate-itar class hierarchy. 

Both diagrams show that there is a one-to-one correspon- 
dence between data types and iterators over those data 
types. Since we don't want client code to know how the data 
is stored, we need some way to hide this information from 
clients while still providing them with a way to get at the 
data. We use the letter/envelope programming idiom to 
accomplish this."' Clients construct an envelope object gen- 
eral absvissa-itur and general ordinate-iter in the diagram), 
which can then ask the data to construct an iterator over 
itself. Clients never have to know what kind of data is being 
accessed. The envelope and letters are derived from a com- 
mon base class which defines the interface for the iterators. 
The envelope serves as a forwarding object to the real itera- 
tor, die letter. The iterators have an orthogonal interface for 
data retrieval and iterator positioning. There are methods for 
looking at the next and previous data elements (which then 
alter the position of the iterator), methods for peeking at I he 
next and previous data elements (do not alter the position). 
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Fig. II. Partial format specification 
for the Intel P640 microprocessor. 



methods for querying and setting the position of the iterator, 
and methods for testing forward and backward iterator 
exhaustion. Multiple iterators can be constructed to look at 
the same data; this would be the case in a prototype analyzer 
graph that takes advantage of the multiple-view, multiple- 
location use model. Iterators are declared so that they can 
only access the data. We provided no iterator methods that 
would modify the data. 

We also denned an iterator that is a combination of an 
abscissa-itor and an ordinate-iior. The dulii-itur retrieves 
pairs of values representing the value of a label and the sam- 
ple or time at which it occurred. In addition to the orthogonal 



interface described above, this iterator also provides methods 
to report the value and location of the next or previous 
change in the ordinate data. These methods are useful for 
waveform drawing algorithms. 

Row major iteration over multiple correlated data sets is 
aided by group abscissa iterators. These iterators examine a 
list of abscissa-itors (one for each data set in the data group ) 
and return the next or previous x-axis value and a list of 
identifiers that select the data sets from which that value 
comes. These iterators come in handy, for example, in visual 
programming graphs that have multiple analyzers fanning in 
to a single analysis tool (Fig. 15). For a lister display that has 
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niulliple data sets merged (Fig. Hi), we need to show the 
data from the various analyzers interleaved in time as they 
were actually sampled 

Memory Management 

With the increasing acquisition depth and width of HP logic 
analyzers, data sets can have sizes greater than 40M bytes. 
In the prototype analyzer environment, users can be examin- 
ing these data sets in several locations with several views. 
Having so many references to the data can easily lead to 
memory management problems, particularly nasty among 
them being memory leaks and pointers to stale memory. 
A memory leak occurs when a process no longer has any 
references to a chunk of memory that has been allocated 
from ihe heap of memory available to the process, and thus 
there is no way to return the memory back to the heap. As 
an application leaks more and more memory, less is available 
to that process and eventually the application will half be- 
cause of an out-of-memory error. Leaking Very large blocks 
of memory will cause this condition to occur sooner. Pointers 
lo siale memory result when Ihe application does return a 



rig. 14. i irdinate-ltor class hierarchy. 

chunk of memory lo the heap bill keeps other pointers to 
lhat same memory, which the application no longer owns. 

The normalized dala library uses the reference counting 
idiom 0 to overcome these potential problems. Passing a 'lata 
group from one tool to the next creates a copy of Ihe data 
group. These copies result in incrementing reference counts 
lo the individual blocks of data contained in Ihe abscissa data 
and ordinate data object hierarchies. Defining ;m iterator 
over this data also constructs a copy of the data, which 
causes a reference count increase. Destroying Ihe data 
(by deleting a tool ) or deleting iterators causes these copies 
to be deleted, which then causes the reference counts to be 
decremented. When the reference counts reach zero it is 
safe to release the memory back to the heap. At that time we 
are sure no other references to that memory exist. The nor- 
mal execution of a tool includes these steps: 

• Delete the old output data group of Ihe tooL 

• Delete the old input data group of the tool. 

• Construct a new input data group for the fool by merging all 
inputs. 

• Execute the tool (delete old iterators and construe! new 
ones). 



MM 



Fig. 15. A visual prugrammiiig 
graph With multiple analyzers 
fanning in to a single analysis 
tool. 
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Fig. 16. A lister display with 
multiple data sets farmed in. 
The data sets from the various 
analyzers are interleaved in time 
as they were actually acquired. 



• Construct a new output data group for the tool. 

We denned our iterators such that they do not modify the 
underlying reference counted data. In cases where tools need 
to modify the reference counted data (such as pattern filters 
which modify the lags object in a data set ), we use the copy- 
on-wrile optimization: operations that would change the 
data cause a completely new copy of the data to be created 
and cause reference counts to be adjusted accordingly. 

Case Study 

During the design of the normalized data library for the 
pr otot y pe analyzer we made a conscious decision to incur 
the overhead of normalizing the acquisition data immediately 
after transferring the data from the HP 165G0B mainframe to 
the prototype analyzer. This happens once per acquisition 
and before any lools examine the data. We do this immedi- 
alely to optimize the response lime of postacquisilion data 
exploration. For very large acquisitions, however, this nor- 
malization lime can be considerable. 

Al the initial release of I he prototype analyzer, one customer 
was making such an acquisition with lM-byte-deep HP 
[658SA logic analyzer cards probing an Intel P(i micropro- 
cessor and a PCI bus. We found the normalization lime to be 
too large in this case— the acquisition data exceeded -HIM 
bytes. Alter studying where our code was spending time 
(lin ing the normalization process, we optimized certain 
sections of code as well as significantly changed the way in 
which | he dala driver for that module slored the data in the 



object hierarchies. After our optimizations, we reduced the 
normalization lime by a factor of ten. More important, we 
did not need to change a single line of client code (lister, 
waveform, chart, etc. ) lo take advantage of litis optimization. 

Conclusions 

At the introduction of the HP 10505A prototype analyzer we 
met most of our project goals. We duplicated almost all of 
the HP IC500B functionality for Ihe HP 1G55()/4/.VoA, HP 
1()517A, and IIP I6532/3/4A acquisition cards and added sex 
eral significant features such as pattern filtering and multi- 
ple-view, multiple-location data exploration. The ability to 
write a single dynamically loaded shared library for each 
analysis anil display lool that would work for any of Ihe data 
retrieved from the acquisition cards was prominent among 
the reasons we met our goals. We continue lo create new 
analysis and display tools that will help our customers solve 
I heir mosl difficult design problems. 
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A Full-Featured Pentium PCI-Based 
Notebook Computer 



The HP OmniBook 5000 computer takes advantage of new technologies 
such as mobile Pentium, PCI, plug and play, lithium-ion batteries, and hot 
docking to give users the same capabilities as their desktop computers. 

by Timothy F. Myers 



The IIP OniniBook 5000 computer ( Fig. 1 ) marks a change 
in the direction of notebook computers designed l>y Hewlett- 
Packard. Earlier OmniBook products focused on being 
ancillary tools to the conventional desktop PC. The designs 
were biased towards small size, long battery life (or more 
usually, a smaller battery), and the ability to run most major 
programs. They brought to the customer new features such 
as instant -on, battery charging while operating, expandability 
via the PCMCIA standard (now known as PC Card Standard, 
or more simply PC Card), and simplified use As customers 
became acquainted with their mobile computers they de- 
manded that their portables have the same functionality as 
their desktops. Thus began the emergence of color displays, 
larger hard drives, faster processors, and external flexible 
disk drives in the HP OniniBook family. When the C.'orvallis 
Division became the Mobile Computing Division with the 
charter to design, produce, and market a full range of mo- 
bile computers, we realized that we needed to fill a gap in 
HP's computer line; the full-featured notebook computer. 

Full-featured notebook computers today are characterized 
as having the same capabilities as desktop computers, albeit 
with some lime lag for the highesl performing models. Over 
the pasl few years, the spread in processing performance and 
features between notebooks and desktops has narrowed. At 




Fig. l. HP OmniBook r-noo cdinputcr. 



the end of 1995. the gap was only about three lo six months. 
Today's customers not only demand lhal I heir notebook 
have the same capabilities as I heir desktop but also expect 
more in features that make mobile computing easy. In addi- 
lion lo being a desktop replacement the notebook computer 
should provide the same flexibility in prepurchase configu- 
rations and future expandability. 

To facilitate HP's entry into the full-leal tired notebook mar- 
ket we chose lo [tanner with a foreign notebook design and 
manufacturing company to quickly modify and produce a 
product for this segment. While the HP OmniBook 4000 was 
a very solid and feature-rich notebook product, our custom- 
ers quickly requested features that were unique to our origi- 
nal OnimBooks, especially instant-on. Instant-on is a feature 
that allows users to put the machine into a low-power state 
and later resume working exactly where they had suspended 
their work. The main difference between HP's instant-on 
and our competitors' suspend feature is thai the amount of 
lime thai our products can remain in I he suspended state is 
measured in weeks, compared with hours or a couple of 
days for competitors. With the advent of new technologies 
such as mobile Pentium, PCI, plug and play, lithium ion bat- 
teries, and hot docking, we felt that we could design a prod- 
lld that would sel HP apart from many competitors offering 
Pentium notebooks. The HP OmniBook 5000 shows that 
there are still abnndani areas for contribution, even in a 
highly competitive market 

Because of the multiple choices before us in chipset selection 
and peripheral IC technologies, we needed lo have some 
major goals lo guide our design process. While earlier HP 
OmniBooks focused primarily on size, power, compatibility, 
and performance, in that order, our criteria were different. 
Our target market was to be mainly corporate users, so our 
first goal was compatibility: "If we can't run it, they won't 
buy it." If our product makes it difficult to get some program 
or utility working, our customers will pick anodier product. 
The second major goal was performance. If our product is 
not near the lop in benchmark performance, we will not 
appear to be technology leaders. The third goal was power 
management. If our product does not run very long on a 
battery charge it will not be very convenient If we do not 
manage power wisely, the heat generated by the compo- 
nents could affect reliability, functionality, and customer 
satisfaction. Of course, there were other goals, such as con- 
venience, quality, reliability, and functionality. However, the 
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first three guided the decision process for the IIP < UuniBook 

5000. 

Architecture 

The HP OmniBook 5(K)0s architecture is based on a layered 
bus concept. Fig. 2 is a block diagram of the computer. This 
approach allows the devices that need higher data band- 
widths to reside on an appropriate layer (o maximize perfor- 
ntance, power, number of pins, and functionality. The widest- 
bandwidth bus is the Pentium's 64-bit data bus. On litis bus 
are the system DRAM memory, the level-2 cache, the host 
bridge, and the Pentium CPU. The CPl" bus can operate at 
50. 60, or 66 MHz, depending on the CPl* processing speed. 

It is imperative that external memory 'lata be delivered to 
the CPl' as fast as possible. The Pentium processor has 168 
bytes (8K data. 8K code) of internal level- 1 cache, and the 
CPl module can support 256K bytes of external level-2 
cache. The level-2 cache is implemented using burst 



synchronous sialic RAM with fast access speeds so there 
are no wait states other than the address lead-off cycle. 
Because the Pentium CPl" and level-2 cache consume quite 
a bit of power even in a nonclocked state, the power to 
these devices is turned off during suspend periods and the 
control signals from the host bridge are put into a high-im- 
pedance slate (instated I. The host bridge provides the 
DRAM and level-2 control and also serves as a gateway to 
the PCI bus. 

The system DRAM can be arranged into four logical banks 
in two physical slots. The user can select from 8M to 04.M 
bytes of memory in granularity of 8. 16. 24. 32, 40, 48. and 
64M bytes by combining SM-byte. lOM-byte. and 32M-byte 
modules. The DRAM supports self -refreshing, so when tite 
I IP ( >mniBook 5000 is suspended, the DRAM retains its con- 
tents without clocks or signals from the host bridge. All 
DRAM memory Is removable and accessible which makes it 
easier to replace and upgrade. 
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PC I -Based I/O Architecture 

The HP OmniBook 5000 I/O bus architecture is designed 
around the Peripheral Components Interconnect (PCI) bus. 
The PCI bus in the HP OmniBook 5000 is designed to run at 
33 MHz for all proc essor speeds. At 32 bits of data width, the 
theoretical bus transfer rate at burst speeds is 132 Mbytes 
per second. This overabundance of data transfer bandwidth 
allowed us to add many devices to the PCI bus to increase 
system performance. The video, SCSI, and 16-bit PC Card 
(formerly PCMCIA) controllers all reside on the PCI bus 
along with the CPU host bridge and the ISA (Industry Stan- 
dard Architecture) bridge. The SCSI controller, the CPU host, 
bridge, and the ISA bridge are capable of bus mastering, 
which allows them to assume control of the PCI bus. 

The PCI-to-ISA bridge contains the power management unit 
that controls the CPl ' docking and peripheral power states. 
The ISA bridge also contains the standard PC-compatible 
components such as the interrupt controller, the DMA con- 
troller, system timers, memory mappers, and the ISA bus 
interface. This IC translates the 32-bit PCI bus commands 
and data that are directed to the 16-bit ISA Bus. 

The CPU clocks are managed by using a clock throttling 
scheme. This method was developed for the Pentium CPU 
since it has an internal fractional frequency multiplier to 
allow higher processor speeds while limiting the external 
bus speed. Because of this multiplier function, one cannot 
just slow down the CPU's frequency to reduce power con- 
sumption as was done in previous products. Instead, the 
power unit makes a request to the CPU for permission to 
stop the clock. The CPU responds by issuing a special bus 
cycle when it is finished with the current instruction and 
then stops its internal clock. When an external event such as 
<m I/O or timer interrupt occurs, the power unit releases the 
request signal and the CPl ' restarts its internal clock and 
resumes operation. Fig. 3 shows die tinting of the stop-clock 
function. 

The ISA bridge includes a 32-bit IDE controller, which allows 
faster disk accesses with newer operating systems. This IC 
redefines the ISA bus during idle cycles to handle the 16-bit 
IDE hard drive controller signals. Buffers provide isolation 
between the IDE and ISA buses and allow the hard disk to 
be powered off while the system continues to function. 

Video Controller. The HP OnmiBook 5000 video controller 
features LCD panel (DSTN or TFT) and external video inter- 
faces with VGA or SVGA options. In addition, die video sys- 
tem provides NTSC/PAL video output (the video used in 



VCRs or camcorders) to allow presentations to be displayed 
on a standard TV monitor or recorded on a VCR for playback 
a! a later date. 

The video controller resides on the PCI bus so that data from 
the CPU is quickly written to the video memory. The video 
memory provides a lM-byte video space for up to 64 million 
colors in 640 x 480 VGA mode. It also has a 0.5M-byte frame 
buffer to increase the performance of the dual-scan (DSTN ) 
LCD. The memory on the video controller operates at. 3.3V 
to conserve power and reduce heat. The video I) RAM's self- 
refresh mode preserves the video screen data while the HP 
OmniBook 5000 is suspended and clocks to the video con- 
troller are stopped. 

The video circuits automatically detect when a user con- 
nects either SVGA or NTSC/PAL video cable to the HP Onmi- 
Book 5000. The BIOS will detect the appropriate monitor 
type and enable the proper video settings based on I he 
selections made in the system setup utility. This feature 
makes it easier for the user to set up presentations quickly. 

16-Bit PC Card Controller. The PC Card controller resides on 
the PCI bus to allow for several features. By making this 
controller a PCI device, we are able to map it to a different 
I/O address should there be a conflict with a legacy ISA card 
in the docking station (described later). This design makes it 
possible to support new PC Card standards (e.g.. Cardbus, 
based on 32-bit PCI) in the docking station by remapping or 
disabling the internal controller. We are also able to increase 
the system performance by having PC Card accesses bypass 
the bus translations that would be necessary with separate 
PCI, ISA, and PC Card buses as in the classical implementa- 
tion. Performance is also increased because devices that 
support DMA (e.g., the sound card) do not slow down CPU- 
to-PC Card transfers (i.e., networks). The HP OmniBook 
5000 design has two slots for either two type II cards or one 
type 111 (double-height) card. The interlace software allows 
the cards to be shut off completely during suspend mode 
and to be restored when operation resumes. Device drivers 
are designed to support advanced power management calls 
(described later) to prevent disk corruption during suspend 
mode. 

SCSI Controller. The SCSI controller option on the IIP Omni- 
Book 5000 is provided to give the user a simple way of con- 
necting to external devices such as CD-ROM. external hard 
disks, backup tape drives, and scanners. This versatile inter- 
face provides a high data transfer rate (up to 10 Mbytes per 
second). The SCSI interface can be disabled when not in use 
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Fig. 3. Timing of the stop-dock 
(Ainction used for power conservation. 
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to conserve power. A SCSI BIOS is provided so no drivers 
are required to operate a SCSI hard disk if it is connected 
when the system boots. This SCSI BIOS SOppOtta the SCAM 
protocol, which allows the user to set the SCSI IDs for S( AM- 
equipped devices from the HP OmniBook 5000 keyboard to 
simplify setup. 

Special device drivers were written to support advanced 
power management calls to prevent read/write operations lr> 
the disk from being interrupted when the user tries to go 
into the suspend mode. Tliis feature helps prevent corrupt 
disk images resulting from mobile use. which was not taken 
into account when the SCSI standard was developed. 

Keyboard Controller 

The keyboard controller in the HP OmniBook 5000 provides 
the personality of the notebook. It performs many of the 
notebook-related tasks so that the Pentium CPC can remain 
focused on compatibility anil performance. Some of the 
tasks performed by the keyboard controller are: 
Keyboard scanning 

Support for three PS/2 polls (internal trackball, external 
Blouse, external keyboard) 
Status panel control 

Battery charging and low-voltage monitoring 
Battery capacity gauge communication and tutoring 
Temperature sensing and thermal feedback control 
Inlerface to EEPROM for passwords. PC Tattoo, serial 
number, and other system tunable parameters 
Docking station control 
Power on/off control. 

Because of the complexity of I he tasks it has 10 perform, the 
keyboard controller is flash-memory-bascd so llial ii can be 
reprogrammed in the field along with the system BIOS and 
the EKPKOM that contains user and system tunable parame- 
ters for battery charging, voltage detection, and so on. A 
special technique was implemented to perform the in-circuit 
programming of the flash memory in the keyboard controller. 
First, a bootstrap program is downloaded to the keyboard 
controller HAM space and executed. This program lakes 
over the keyboard controller and handles the communication 
wild tlii' Pentium, Tbe Pentium downloads Ihe Hash update 
program into the keyboard controller's RAM. The Hash 
memory inside the keyboard controller is erased and then 
the new keyboard controller BIOS is transferred to Ihe key- 
hoard controller and programmed into Ihe flash memory. 
I pon a hard reset, ihe keyboard controller begins function- 
ing w ith I lie new BIOS. 

The keyboard controller has eight 10-bit analog-to-digital 
converter (ADC) channels, which are used to monitor Ihe 

battery temperature for each of ihe two battery slots, the 
CPU temperature, the ambient temperature, both battery 
slot voltages, and a 2.5V reference. The voltages read by the 
ADC channels are digitally filtered by the keyboard conl roller 
before being used by Ihe system BIOS. 

The keyboard controller also handles talking to v arious l/i ) 
pi M is such as three PS/2 channels. I wo Bcnchmarq small 
battery channels, and an I-C interface. Events llial have 
higher priorities are serviced first by Ihe keyboard controller, 
if the keyboard controller is servicing a lower-priority task 
and a higher-priority evenl occurs, il is processed first and 



the lower-priority task is rescheduled. The highest-priority 
tasks are docking and low-batten' detection, then keyboard 
and mouse-related tasks, followed by housekeeping chores 
of battery charging, battery capacity monitoring (see below j. 
and status panel ii|>dating 

Smart Batteries with Tutor Assist 

ICs in the HP OmniBook 6000 battery packs allow the bat- 
tery packs to retain their charge state and status information. 
If the battery is removed from the HP OmniBook 5000 and 
used or charged in another device, the capacity of the bat- 
tery is reread from the pack when it is reinserted. These 
"smart" batteries can measure their temperature and current 
flow and perform compensated updates of the bailer, capac- 
ity gauge so that , over time, the gauge contents do reflect 
the stale of Ihe battery. 

Although there is quite a bit of intelligence designed into the 
battery capacity gauge circuits, there are events and bound- 
ary conditions that result in the gauge's not representing the 
capacity of ihe battery accurately. One example is the firsi 
lime the battery pack is assembled. The capacity gauge re- 
quires that the battery pack be discharged and then charged 
back to a full state to calibrate and initialize the battery 
capacity reference. So that the user does not have to per- 
form this function, the HP OmniBook 5(100 will calibrate the 
pack under certain conditions when il knows the battery's 
charged state. At those limes, the HP OmniBook 5000 will 
compare the pack's battery capacity reading and if it dis- 
agrees with the HP OmniBook 5000s own gauge by a fixed 
factor, the pack's gauge will be updated. This tutoring ap- 
proach provides a closed-loop system to help correct for any 
inaccuracies caused by component tolerances, bad assump- 
tions by the smart battery, current cresl factor corrections, 
and Charging inefficiencies, With Ibis approach, Ihe user 
does nol have to be involved in Ihe recalibralion of the bat- 
tery pack. The philosophy is that, even with machines, two 
heads are heller I ban one. 

Power Supply and Battery Charging 

The power supply general es M.:iV. 5.0V. and 12.0V. II can 
charge eilher a N'iMHy battery' using a constant current 
source or a Li-Ion Battery using a constant current/const an I 
voltage source. The ac adapter is the same as that used by 
Ihe HP OmniBook fiOO Series. Il provides an output of 12V at 
3.3A maximum current or a total power of about 10 walls. 
Half of Ihe adapter wattage is used to operate Ihe product 
an<l half is used to charge the batteries in the system. The 
battery voltages for both the NiMIly and Li-Ion packs can 
each be higher or lower than the + 12V adapler voltage, de- 
pending on the charge slale of Ihe cells. A flyback configura- 
tion is used in the adapler since il can be designed to support 
this voltage span (see "Flyback Charger Circuit" on page 42). 
The power to the batteries during charging is limited by both 
currenl and voltage sensing. An important convenience goal 
of the HP < (mniBook 5000 was to charge and operate at Ihe 
same lime. This feature allows the user to operate Ihe III 1 
OmniBook 5000 during the day and slill have full batter; 
power for ready use after disconnecting the computer from 
the ac adapter. 

The &8V and 5.0V regulators use a synchronous switching 
topology Dial allows Ihe power supply to maintain a high 
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level of efficiency. The + 12V output is derived using a trans- 
former tap on the 3.3V inductor to generate about 14V, which 
is then linearly regulated back to + 12V. This technique gen- 
erates a very clean and stable + 12V to program the system 
Hash memory, the keyboard controller flash memory, and 
any IV Card memory cards. Sometimes the + 12V is used 
for analog circuits on PC Cards, so we felt it necessary to 
provide a filtered signal. 

( >ne challenging design parameter of the power supply is 
that it must deliver about 15W during maximum operation 
and also maintain regulation while supplying less than 
100 mW to the system in suspend mode. 

Docking Strategy 

The IIP ( >mniBook 5000 docking station (Fig. -I ) provides the 
docked computer with one PCI slot and 2 ISA slots, giving 
the user access to the same options as desktop users. The 
docking station provides one-handed, power-assisted docking 
(VCR style). The I/O ports on the HP OmniBook 5000 are 
replicated on the docking station so that the user does not 
have to remake a lot of cable connections. Some ports, such 
as the sound system (line in. line out, and microphone), MIDI, 
and SVGA out ports, are passed straight through the doc-king 
station. Other interfaces such as the SCSI, RS-232, parallel, 
and game ports are replicated by using the same ICs as the 
HP OmniBook 5000's internal chips, which are disabled. By 
using the plug and play features of the BIOS, the docked HP 
OmniBook 5000 can have either the same configuration as 
the portable HP OmniBook 5000 or a different configuration. 

Control of the docking sequence is handled by the keyboard 
controller using some control signals and the I 2 C bus. The 
I-C bus is \ised to read and write additional signals and to 
save and restore configuration information for the docking 
station. Fig. 5 shows the timing of the docking sequence 

The user initiates the docking event by placing the HP Omni- 
Book 5000 on the docking station's receiving tray and pro- 
viding a gentle shove. When the docking station's detection 
switch is activated, the motor engages and captures the IIP 
OmniBook 5000 and draws it onto the connector. When the 
docking connector guide pins begin to mate into the HP 



Flyback Charger Circuit 

The flyback transformer design of the HP OmniBook 5000 charger 
circuit can provide a wide range of output voltages because of the 
energy storage, coupling, and isolation of the transformer (see 
Fig. 1|. During the first portion of a clock cycle, energy is stored in 
the primary side of the transformer During the second portion of 
the clock cycle, the energy is transferred to the secondary wind- 
ing via the core's coupling Because the current in the primary is 
cut off abruptly, the secondary voltage can become higher than 
the input (dl/dt is high and V = Ldl/dt). 

The secondary output current charges a large output capacitance. 
Using a high-frequency clock, the output capacitor's voltage can 
be charged up to any desired level and then the converter's con- 
trol circuitry can be shut down until the output voltage has 
decayed by some desired amount for regulation. 

The isolation of the secondary winding allows for both voltage 
and current sensing to control the flyback operation This permits 
both current and voltage limiting, which are required with Li-Ion 
batteries. For current sensing, the voltage across the sense resis- 
tor is filtered and compared to a set reference When the output 
voltage has risen high enough to cause the desired current in the 
battery, the control circuit is turned off Again, when the current is 
reduced by a desired amount to maintain regulation, the control 
circuit is reactivated. 
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Fig. I, Flyback charger circuit 




OmniBook 5000 the keyboard controller is notified by a non- 
maskable interrupt and it notifies the chipset that a hot-dock 
event is about to take place. The chipset then halts the Pen- 
tium processor and tristates the buses. When the two con- 
nectors mate, the keyboard controller is notified by a signal 
on the connector. The keyboard controller verifies that the 
docking station has a valid power good signal, and if it does, 
the keyboard controller signals the chipset to release the 
Pentium and begin driving the PCI and ISA buses. The BIOS 
first disables the internal I/O chips and configures the I/O 
chips on the docking station before allowing the user to re- 
sume work. Depending on the operating system on the HP 
OmniBook 5000. a reboot of the operating system may be 



Fig. 4. HP OmniBook 50(10 computer in docking station. 
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Sensor that detects that the OmniBook 5000 is present and ready lor docking. Starts the 
dock motor lor VCR-style docking. Moves the OmniBook 5000 into the dock connector. 
Sensor that detects that connectors are about to mate. Alerts the keyboard controller to 
begin the docking sequence to instate the system buses. 

PCI and ISA buses are tristated to prevent data corruption during docking and undocking 
sequences. 

Signal that the connectors have mated. 

Signal read by the keyboard controller to verify that a good docking event has occurred 
and the system can resume. II the dock power good signal is not detected, the system is 
powered off. 

Button or software event to initiate the undock soquence. 



necessary to load device drivers for SCSI peripherals or 
other cards thai may be plugged into the slots. 

The undock sequence begins when the user either presses 
the undock key on the docking station or initializes an tin- 
dock sequence via the operating system (Windows® 95). 
When the keyboard controller receives the undock event il 
signals the chipset to halt the Pentium once again and re- 
leases rnnirnl "I flic buses. Il then signals 1 1 it- din-king sin- 
lion via the PC bus to begin ihe undock sequence for I he 
motor. The motor stalls and begins to eject the HP Omni- 
Book 50(10 from the docking station. The keyboard control- 
ler detects thai undocking has occurred by monitoring the 
docking detect signal. It then tells the chipset to release the 
Pentium and drive the buses again. The BIOS then reconfi- 
gures the I/O devices back to the mobile configuration. 
Again, depending on the operating system and selection of 
peripherals, il may be necessary to perform a reboot. 

CPU Thermal Management 

The Pentium CPU has a maximum thermal envelope of about 
7.5W, This power is dissipated as heal in the CPU. The IIP 
OmniBook 5000 combines many techniques to remove the 
heat from the CPU to ensure both functionality and reliabil- 
ity of the product The tape carrier package (TCP) version of 
tile Pentium is used to allow the case temperature of the CPU 
lo be higher than is allowed in the standard ceramic package. 
The TCP package is essentially a metal plate attached to Ihe 
backside nf ihe CI'I ' die. The pads on the eircuil side of ihe 
CPU connect to thin-film conductors on a piece of cellulose 
(which looks similar to 35-nim film) ml her than using tradi- 
tional bonding wires. The top side of the die and film are 
ihen covered with an epoxv coating lo protect ihe bond COn- 
nec lions and lo seal Ihe die from coniaiuinanls. The net ef- 
fect of Ibis package is that the thermal heal resistance from 



Fig. 5. Docking sequence timing 
diagram. 

Ihe CPU lo Ihe outside mounting pad of the package is mini- 
mal. This feature allows us to operate the case temperature 
at 95°C versus 75°C for the PGA package. 

The TCP package has very little I hernial mass, so we need to 
move the heat energy away from Ihe package and out into 
the product. Aluminum cast heat sinks are attached to two 
sides of the CPU package, both lo the package epoxy and lo 
the backside of the package through the use of many via 
holes under Che die. This approach moves the heat energy 
away from the CPU to a larger mass for further disposal out 
of the product. 

To get the heal out of the product the cast heat sink is at- 
tached lo an extruded aluminum heat sink, which attaches 
to the back aluminum I/O panel. This heat sink lias the 
ridges found in typical heat sinks so that the heat can con- 
vert out of vents in the top case. 

To remove additional heat from the cast CPU heal sink, a 
heat pipe technology is used (see Fig. <>). A heat pipe is basi- 
cally a small Carnot engine that transfers heat from one end 
of the pipe to the other via a temperature differential, using 
a wicking action lo recycle the fluid. The fluid in the pipe is 
just water that has been depressurized to allow il to boil at a 
lower tempetattoe. When the CPU heal sink is healed to the 
boiling point of the water in the heat pipe, the water changes 
stale from liquid to gas. Tliis phase change' extracts a large 
amount of thermal energy from the heat sink. As the water 
boils, the wick inside the heat pipe brings cooler water to 
the CPU end and the gas moves down the heat pipe to the 
condensing end. When the gas in the heat pipe cools below 
the boiling point, the energy taken from the CPU is released 
into Ihe condenser. The condenser consists of a thin alumi- 
num stamped sheet. This sheet is attached lo the back of the 
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Fig. 6. Ueai pipe principle. 

metal plate of the keyboard and the heat is spread out over 
the keyboard surface area. 

To prevent the CPU from generating excess heat dining typi- 
cal operation, the chipset provides different methods of con- 
trolling the CPU activity with the use of ail rained power 
management (APM). Software APM is the most effective. It 
consists of having a running program shut the CPU clock 
down when there are periods of inactivity in the program. Of 
course, this method requires I he soft ware to he APM com- 
pliant. If the user is operating software that is not APM com- 
pliant, the IIP OmniBook 5000 can be set to use hardware 
APM as a default. Hardware APM is implemented by moni- 
toring the interrupts and major I/O function accesses. When 
the program is performing any I/O activity or the I/O devices 
generate an interrupt, a timer is reset that keeps the CPU 
active from one half second to eight seconds, depending on 
the setting. If another event occurs before the timer times 
OUt, the timer will be set back to the full count. If the pro- 
gram is just executing out of the CPU memory and die timer 
expires, then the CPU clock is throttled back to 1/4 speed. 
This reduction lowers the power used by the CPU by about 
75%. Access to an I/O event will again set the timer to the 
full count and enable the CPU to run at full speed again. 

To prevent the CPU from reaching the critical case tempera- 
ture, active thermal feedback is employed. This technique 
measures the temperature of the CPU module and the ambi- 
ent air inside the imit. The temperature limits for each are 
monitored by the keyboard controller. If eidier limit is ex- 
ceeded, the CPU speed is reduced by clock throttling. When 
the CPU and ambient temperatures cool below their restart 
thresholds, the keyboard controller will again allow the CPU 
to work at full speed. For the thermistor on the CPU mod- 
ule, the feedback is fairly rapid because of I he mechanical 
heat removal methods, and the CPU tends to run at an aver- 
age clock speed at which thermal equilibrium is reached for 
the given operating conditions. In the case of the ambient air 
sensor (used to protect other ICs in the notebook from over- 
heating) the effect of slowing down the CPU is not very rapid 
because of the large thermal resistance between the sensor 



and the CPU module. If this sensor trips the thermal feed- 
back, the unit will run at a slower speed (1/2 clock rate) until 
the air temperature returns to a cooler level. This rate was 
chosen so that the user can still operate the machine even if 
it takes several minutes for the ambient air to cool. 

Summary 

The technologies developed for the HP OmniBook 5000 
computer are designed to achieve the notebook features 
required for the future. The PCI bus will allow higher speed 
and functionality in video and communications than is pos- 
sible today. The heat transfer and modular assembly tech- 
nologies will permit incorporation of new faster processors 
as they become available. The Li-Ion batteries will continue 
to provide more energy for a given weight, thereby making 
possible lighter products or longer battery life. The instant-on 
feature allows the user the freedom to work whenever it is 
convenient, thus helping the customer adapt to a more mo- 
bile lifestyle. The PCI and ISA hot-docking technology allows 
the user to have full desktop functionality and performance 
when purchasing a notebook computer. 
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A Graphing Calculator for 
Mathematics and Science Classes 



The HP 38G calculator allows teachers to direct students and keep them 
focused while they explore mathematical and scientific concepts. It 
features aplets. which are small applications that focus on a particular 
area of the curriculum and can be easily distributed from the teacher's 
calculator to the students'. 

by Ted W. Beers. Diana K. Byrne. James A. Donnelly, Robert W. Jones, and Feng Yuan 



The HP 38G calc ulator is a graphing calculator for students 
and teachers in mathematics and science classes. It features 
aplets. which are small applications I hat focus on a particu- 
lar area of the curriculum and can be easily distributed from 
calculator to calculator. This allows the teacher to send an 
electronic story problem to each student in the class. 

The HP 38G is built on the same software platform as the 
HP 48G family of graphing calculators,' but has a simpler 
user interface and feature set. Equations are entered using 
algebraic format rather than the reverse Polish notation 
(RPN) found in most HP calculators. The features of the 
HP 38G include: 
Graphical user interface 

Function, polar, parametric, stairstep, cobweb, histogram, 
scatter, and box and whisker plots 
Side-by-side split screen 
Tables 

Unlimited, scrollable history stack 

Symbolic equations 

HP Solve numeric rool finder 

Equal ion Writer display 

Statistics functions 

Matrix operations 

User programming. 

The hardware platform ol'lhe IIP 3SG is very similar to that 
of the IIP 48G: they both have 32K bytes of RAM. 512K bytes 
of ROM. the same ( PI ' and the same display ( 131 by 64 pix- 
els). They both have a two-way infrared link for sending 
information to a printer and for transferring information 
between two calculators, and an RS-232 link for calculator- 
lo-computer communications. An accessory that allows the 
calculator screen to be displayed with ;ui overhead projector 
works with both the HP 48G and the IIP 38G. but the HP 
38G cable connector has been modified so that the overhead 
display accessory works with every IIP 38G; no special 
handsel is required. 

The HP 18 case was redesigned to include a sliding plastic 
COVer to make the IIP 38G more durable for use by youngei 
students. Also, two keys were removed to give visual em- 
phasis to the navigation keys and to make the keyboard look 
less complicated, 



Designed for and with Teachers 

We set out to design a graphing calculator for precalculus 
students and teachers. To help us do this, we formed an 
Education Advisory Committee consisting of eight high 
school, community college, and university teachers. We met 
with the teachers every few months, and between meetings 
we kept in touch by email. 

The teachers told us that they want to allow students to ex- 
plore mathematical and scientific concepts, and at the same 
time they need to direct the students and keep them foc-used. 
In our first meeting with the teachers, we compared this to 
the idea of a child's sandbox: the child is given toys for play- 
ing and exploration, but within a protected, specialized envi- 
ronment. Thus, one of our main goals with the calculator 
software design was to encourage exploration by limiting 
choices. This led us to the concept of n/ilcls: an aplel is a 
small application that focuses on a particular problem. 

IIP 38G Aplets and Views 

We based the design of aplets on the National Council of 
Teachers of Mathematics "three views": graphic, symbolic, 
and numeric. Each problem can be explored using these 
different representations. For example, a mathematical 
function can be expressed as a graph (Fig. la), in symbolic 
form ( Fig. lb), or using a table of numbers ( Fig. 1c), 

Aplets can be created by teachers I either directly on the IIP 
38( i or with the assistance of a computer) and then "beamed" 
to the students' calculators using infrared transfer. This way, 
a whole classroom full of students can have their calculators 
programmed identically at the beginning of a lesson. Then, 
the students can explore within the aplet on their own 
calculators. 

Each aplet packages the formulas, settings, anil other infor- 
mation associated with a particular problem. If the user 
wants to switch from one aplet to another, this can be done 
without disturbing any individual aplet s settings, since they 
are compartmentalized. 

Several aplets are built into the 1IP 38G. When the calculator 
is first turned on, these built-in aplets are empty. The user 
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Fig. I, Willi the HP 38G calculator, a mathematical function 
can be expressed (a) as a graph, (b) in symbolic form, or (c) 
using a table of numbers. 

must add some information, such as equations, notes, or 
sketches to make these aplets come alive. 

Using Aplets on the HP 38G 

Six different types of aplets are built into the IIP 38G: func- 
tion, parametric, polar, sequence, statistics, and solve. Typi- 
cally, a teacher will slart with one of these aplet types, then 
customize it by adding particular functions that define a 
certain problem, together with settings, pictures, and text 
directions. 

To start using a part icular aplet I hat is already in the calcu- 
lator, I he student chooses it from the HP38G library by 
pressing the LIB key. Continuing to explore the problem, the 
student may want to view the problem in different ways, and 
can do this by pressing the different view keys. PLOT. SYMB. 
and NUM display the graphic view, symbolic view, and 
numeric view, respectively. Additional views, such as split- 
screen \iews (Fig. 2 ), can be found by pressing the VIEWS key. 




The student or teacher can customize the graphical, niuneric, 
and symbolic views for a specific problem by using the setup 
screens. It is also possible to annotate the problem by typing 
some text into the note view or by adding a sketch to the 
sketch view. 

The teacher and student can easily generate custom aplets 
that present new examples based on the built-in aplel types. 
An aplet is created by working with an aplet type and adding 
all of the customizing information that relates to a particular 
problem (see art icle, page 59). 

Main Components 

The keyboard (Fig. 3) reflects the seven main components 
of the HP 38G's functionality (from top to bottom on the 
keyboard): 

Softkeys for accessing custom behavior defined by soft key- 
labels along the bottom of the display 
> View keys for moving among the possible representations of 
aplet data 

Library key for selecting the current topic of exploration 
with aplets 

Arrows keys for screen and menu navigation 

Home calculator keys for numeric entry and basic calculator 

operations 

Alpha keys for access to alphabetic characters 

Editing environments for creating, editing, and managing 

objects such as programs, matrices, lists, and notes. 

Four of the key groupings are related as follows: first, a 
lopic is chosen with I he library key. Then, a way of looking 
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Fig. 2. The plot-table view is a typical split-screen view 



Fig. 3. HP 3HC. calculator 
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at the problem is chosen with the view selection keys. 
Finally, the peculiarities of the problem view are manipu- 
lated with the soft keys and the arrow keys. 

Softkey, 

The softkeys are the top row of unlabeled keys, which are 
associated with the dynamic menu labels displayed along the 
bottom of the screen. They give access to contest-specific 
custom behavior. Inlike the HP 48G. there is no "next-row - 
key since all HP 38G softkey sets are limited to six items for 
the sake of simplicity. 

Mew Keys 

The view keys provide one-key access to the three National 
Council of Teachers of Mathematics representations of aplet 
data; graphical, numerical (tabular), and symbolic, plus 
annotation and sketch views for documenting a topic. Keys 
for setting up view : parameters and managing split-screen 
views are also included. 

The plot view gives a conventional mathematical graphical 
representation. In most cases it looks like some flavor of 
plot output in the HP 480. 

The numeric view is generally a table of sampled values. It 
is a derived form of the mathematical objec t (except for 
statistics, where it is Ihe defining view). 
The symbolic view is generally an expression representing 
the mathematical object of interest. The variables are defined 
by the aplet. This view is the defining form of the mathe- 
matical object (except for statistics, where it is derived). 
The note view is a mini word processor that allows the user 
to create, edit, and view a text document associated with 
the aplet. 

The sketch view is a set of standard-sized GROBs (graphic 
objects in HP 480 terminology) that explain the "story" of the 
aplet The user can create, edit, view, and animate pictures. 
Editing capabilities include lines, boxes, circles, lexl labels, 
and Eleh-a-Skelch-stylc drawing. 

Moving from view to view is the same as task switching, 
which means Ihe user can always go on to the next task, but 
there is no concept of going back to somewhere, since tasks 
are not being nested. 

The LIB key invokes the library, which is the aplel selection 
and management environment, in which different aplets 
(including those that are not built-in) can be started, 
exchanged with others, and created by saving the state. 

The VAR key provides access to variables and Ihe MATH key 
provides access to scientific functions and other operations 
and commands. These variables and operations are available 
whenever the user is using an edit line. 

Invoking tin- VAR or MATH menu starts a sublask, which must 
be completed or cancelled, at which point Ihe calculator is 
hack where it was when the sublask was started. 

The Library Environment 

This environmenl gives high-level access to aplets. The user 
can select an aplel and manage the current collection of 
aplets I'rom within the library', Ihe user can lake a snapshot 
of a built-in aplet, giving it a name and a directory of its own. 
This is how aplets are generated for dissemination and how 



users show their work. Also, the user can import or export 
aplets from the library to another HP 38G or to a computer. 

Arrow Keys 

The arrow keys are used for all direction-oriented operations 
such as tracing a function plot, moving among fields in an 
input form, and selecting commands from a pop-up menu. 

The shift key can be used as a modifier for the arrow keys 
dial signals motion "all the way" in the direction indicated 

Home Calculator Keys 

The home calculator environment gives a familiar tool with 
a nice graphical interface. The user invokes it by pressing 
the HOME key, Inputs are displayed on the left side of a line, 
with the results displayed on the right side of the next line. 

The calculator keys are used to type numbers and to access 
basic scientific calculator functions. The ENTER key is used 
to terminate dala entry, to select operations from menus, 
and in general, to make things happen. Some mathematical 
operations are available on the keyboard and other opera- 
tions and commands are available through the MATH pop-up 
menu. 

The ANSWER shifted key gives access to the variable called 
Ans, which always contains the last result. 

Alpha Keys 

The alpha shift key, A...Z. provides access to the alphabetic 
characters, which are labeled on the keyboard overlay. 
Pressing the CHARS shifted key invokes the character 
browser, which provides access to characters that are not 
on the keyboard. 

I 'nlike the HP 4S(i. there is no alpha lock key to confuse the 
user. The user can either press and release the alpha shift 
key before pressing each alpha character key, or hold the 
alpha shift key down while pressing as many alpha character 
keys as desired. However, an alpha lock toggle softkey is 
provided in some editing environments. 

Editing Environments 

The HP 38G has specialized environments for managing pro- 
grams, matrices, lisls, and notes. When Ihe user invokes one 
of the editing environments, a scrolling choose list of all Ihe 
existing objects of I hat type appears, together with a softkey 
menu. From this environment, objects can be transferred 
between the HP 38G and a computer or another HP 38G. 

• The program environment provides tools for creating, 
editing, storing, sending, receiving, and running programs. 
Variables can be accessed through the VAR pop-up menu. 
Mathematical operations can be accessed from the key- 
board or through the MATH pop-up menu, and programming 
commands can be accessed through the commands section 
of ihe math pop-up menu. 

• The matrix environment provides a two-dimensional matrix 
editor for creating, editing, viewing, sending, and receiving 
matrices. 

• The list environment provides a list editor for creating, 
editing, viewing, sending, and receiving lists. 

• The notepad environmenl provides an environment for 
crealing, editing, viewing, saving, sending, and receiving 
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Fig. 4. A typical inpul form. 

text documents. The tools for editing notes in the notepad 
environment are identical to the editor for the note view. 
The documents created in the notepad environment are not 
handled with an aplet as they are in the note view. The note- 
pad environment can be used for tasks such as creating, 
storing, and viewing lists or notes. 

User Interface 

One of our goals for the HP 38G project was to leverage 
software from the IIP I8G/GX calculator platform. For the 
HP 48G/GX we developed two primary general-purpose user 
interface tools: input forms and choose boxes. 1 

Input forms and choose boxes are interactive environments 
that are used to gather user input for a task. Inpul forms (see 
Fig. 4) are flexible, screen-sized dialog boxes similar to 
those in other graphical user interfaces. The appearance and 
use of input form fields resemble spreadsheet programs. 
Choose boxes (see Fig. 5) are either pop-up or screen-sized 
boxes optimized for selecting or working with one or more 
items from an arbitrarily long list. Input forms and choose 
boxes, along with some other user interface constructs, con- 
tribute to the improved ease of use that distinguishes the HI' 
48G/GX from its predecessor, the HP 4SS/SX. 

In the HP 38G, we found that input forms and choose boxes 
were a good match for the needs of the utility environments 
and most of the nine views available for working with aplets. 

Graphical User Interface Applications 

Input forms are used in most aplet views for entering a mix 
of settings and values. They're also used forgathering input 
to complete a task. For example: 
The function aplet's plot setup view is an input form in 
which modes and parameters are specified (see Fig. 6). 
The solve aplet's numeric view is an input form whose ap- 
pearance varies according to the equation to be solved (see 
Fig. 7). The flexible layout and labeling of input form fields 
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Fig. 6. The function spiel's plot setup view input form. 

are employed to generate a custom input form each time the 
view is entered. 

When an aplet is to be saved, a simple input form is displayed 
to get the new aplet's name (see Fig. 8). 
The statistics symbolic view is a highly customized input 
form that scrolls to show more information than Tils on one 
screen (see Fig. 9). Choose box elements, like the tip and 
down arrows indicating more information is available off- 
screen, help suggest the operation of this hybrid view. 

Choose boxes are used in a variety of views mid utility envi- 
ronments wherever a list of related items needs to he man- 
aged. Here are a few examples of choose boxes in the IIP 
38G: 

The aplet library (see Fig. 10) is actually an elaborate choose 
box. 

Almost all symbolic views, such as the function aplet's 
symbolic view (see Fig. 11), are choose boxes. 
Choose boxes pop up within input forms like the MODES 
inpul form (see Fig. 12). 

The VAR and MATH menus (see Fig. 13) are two-column 
choose boxes that show categories of items plus the items 
in the selected category. 

As these examples illustrate, the look and feel of HP48G/GX 
inpul forms and choose boxes remain largely unchanged in 
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tlip HP 38< i. However, substantial reengineering of the under- 
pinnings of these tools was required to match other aspects 
Of the HP HOG'S use model, as discussed in the next sec tion. 

Topic Outer Loop 

Many of the custom interfaces developed for the HP 48S/SX 
used an RPl^-language tool we developed called the parame- 
terized outer loop. 8 Parameterized outer loop applications 
depend on the parameterized outer loop for routine key and 
error handling and display management. The graphical user 
interface (Gi l) elements introduced in the HP 48G/GX are 
;ilso parameterized outer loop applications that automate 
routine matters of input entry, selection of options, and 
presentation of output. 

In both the HP 48S/SX and the HP 48G/GX, the user interface 
was based on the notion of having a c entral environment 
(the user stack I from which other applications are launched 
and to which applications return when completed. All appli- 
cations on these platforms, including parameterized outer 
loop applications like the GUI tools, are based on this 
"function call" model: they start, run for a while, then end, 
returning the flow of control to where they started. We call 
such applications modal. 

New Model, New Tool 

When we were investigating the use model for the I1P38G, it 
became apparent that the function call approach to applica- 
tion management would not suffice. The IIP :iK<; is a tool for 
exploration, so we wanted to provide an environment that 
promotes wandering from one subject area to another, or in 
HP38G terms, from one view oraplct to another. 

To attain this goal we quickly determined that the modal 
nature of the parameterized outer loop and the applications 
based on it was too constraining, yet we weren't prepared to 
discard the wealth of useful tools and concepts we had built 
up from the parameterized outer loop foundation. Further- 
more, we knew there were still plenty of times when the 
modal call-and-return interface would still apply, such ;ls 
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Fig. IL Tin- function apjpt's symbolic view. 

when pausing to get further input from the user before pro- 
ceeding with a task. To acconunodate all these needs, we 
developed the new lo/nc miter hmp. 

Topic Outer Loop Overview 

Where parameterized outer loop applic ations are designed 
to preserve the environment from which they're launched 
;uid later restore that environment, topic outer loop topics 
are optimized for rapidly setting up and switching from one 
topic to the next. Exc ept with regard to the home environ- 
ment from which the topic outer loop is originally launched 
and to which it ultimately returns — after running many top- 
ics, perhaps — the topic outer loop doesn't preserve or restore 
a previous user interface since there is none to go back to. 

The most obvious examples of topic outer loop topics in the 
HP 38G are aplets. but many other environments with simi- 
lar behavior are also topic outer loop topics — for example, 
the aplet library and the user program c atalog (see Fig. 1-1 ). 

Like the parameterized outer loop on which it's based, the 
topic outer loop is launched from the calculator's system 
outer loop and temporarily redefines the current user inter- 
face until some exit condition is met. By design, the topic 
outer loop operates very similarly to the parameterized 
outer loop, but differs front the parameterized outer loop in 
two fundamental ways: 
• To belter support the standard two-tiered structure of IIP 
.'i8G topics, the topic- outer loop manages two nested user 
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interface levels. The paramet erized outer loop manages just 
one. 

The topic outer loop fully supports organized and efficieni 
switching from one topic to another. The parameterized 
outer loop is designed to shut down completely before 
launching another application. 

The operation of the topic outer loop for starting a topic can 
be summarized as follows: 

If a topic outer loop is already running { 

Evaluate the old view exit handler 

Evaluate the old topic exit handler 

Set the topic entry and exit handlers 

Evaluate the topic entry handler 

Set the view entry and exit handlers 

Evaluate the view entry handler 

Set the remainder of the view user interface 

) 

Else { 

Save the home user interface 

If error in { 

Set the topic entry and exit handlers 

Evaluate the topic entry handler 

Set the view entry and exit handlers 

Evaluate the view entry handler 

Set the remainder of the view user interface 

If error in { 

While not done with the topic outer loop { 
Evaluate the view display object 
Read a key and get its custom definition 
If error in 

Evaluate the key definition 
Then 

Evaluate the error handler object 

) 

Evaluate the view exit handler 
Evaluate the topic exit handler 

j 

Then { 

Evaluate the view exit handler 
Evaluate the topic exit handler 
Error 

) 

) 

Then { 

Restore the saved home user interface 
Error 
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Fin. 14. The user program catalog, a topic outer loop utility 

environment. 

The code sel ling up I he topic specifies the user interface and 
other environment elements unique to the topic, such as the 
topic entry handler and the view display object, when it runs 
the lopic outer loop. This is how the behavior of the topic 
outer loop is customized. The topic outer loop is responsible 
for the key-display loop, low-level error handling, and juggling 
Ihe topic and view entry and exit handlers and the saved 
home user interface. 

When an event occurs that calls for running the topic outer 
loop, the lopic outer loop may or may not already be run- 
ning. As ihe first seel ion of ihe lopic outer loop overview 
Illustrates, if a topic outer loop is already running, switching 
lo a new lopic is quick yel still gives the exiling topic an 
opp o rt u nity to shut down in an orderly fashion. Since it's 
common with the HP 38G to move from lopic to topic with- 
out firsl reluming home, this efficiency translates to faster 
performance. 

Switching among views within the same topic is also com- 
mon, and involves a similarly efficient set of operations: 

Evaluate the old view exit handler 

Set the view entry and exit handlers 

Evaluate the view entry handler 

Set the remainder of the view user interface 

Reengineering the GUI Tools 

Although very similar in specifications and use to the stan- 
dard modal input form and choose box environments, ver- 
sions of these environments based on Ihe lopic outer loop, 
which we call modeless environments, differ in Ihe following 

ways: 

OK and cancel keys are nonfunctional. 

The default softkey set does not include ( >K and cancel 

keys. 

Task-svviiching keys are processed normally to allow task 
swiiching. 

The results returned by the input form or choose box engine 
always consist of the confirmed exit values. No flag indicat- 
ing canceled or normal exit is relumed. 

To support modeless views and utility environments based 
on IIP 48G/GX GIT tools, we adapted the input form and 
choose box engines lo use ihe topic outer loop. However, 
modal input forms and choose boxes are also employed by 
the HP 386. Rather than simply switch Ihe engines from 
using the parameterized outer loop to using the lopic outer 
loop, we modularized the components of Ihe engines to 
enable the use of either. We then repackaged the modal 
versions of the engines to ensure backwards compatibility 
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for existing code using them. To make modeless input form 
and choose box programming as straightforward as possible 
for programmers familiar with the modal versions, and yet 
still meet the requirements of the topic outer loop, we devel- 
oped tools to translate traditional modal input form and 
choose box arguments and results to and from the specifica- 
tions required for topic outer loop applications. This greatly 
simplified the reengineering of existing user interface code 
to make use of new modeless inpul forms anil choose boxes. 
The process was largely mechanical, requiring only thai the 
developer follow a few well-documenied steps. 

Aplets and Mews 

One of the key ideas of aplets is that they provide different 
ways of looking at a problem. For example, when exploring 
a story problem about speed and distance, the student can 
look at a symbolic expression, a table of numbers, a graph 
of the distance fimction. or even a diagram showing a tortoise 
and a hare. These different ways of looking at an aplet are 
called views. The topic outer loop manages the transitions 
between the views of an aplet The views are implemented 
using the graphical user interface tools plus aplet data. The 
data associated with an aplet is encapsulated in a directory 
.structure inherited from the IIP48G/GX. 1 

Aplet Structure 

Associated with each aplet is a standard set of information. 

The topic outer loop uses this aplet information for aplet 

directory checking, topic switching, resetting, and so on. It's 

also used by the VAR menu and the VIEWS choose box. The 

standard information is: 

Topic II) 

Initial view 

Topic name 

Special views data 

A p li -l -speci fie variables 

Topic entry procedure pointer 

Topic exit procedure pointer 

Topic reset procedure pointer 

Aplet directory checker procedure pointer. 

An HP 3SG aplet is a collection of aplet data and aplet views. 

Aplet data includes the aplet name, which is used in the 

library, real variables like Xmin and Xmax, which are set via 

the plot setup view, symbolic expressions, note text, ami 

sketches. An aplet usually defines at least eight v iews: plot, 

symbolic, numeric, note, sketch, plot setup, symbolic setup, 

and numeric setup. The generic aplet contains items such as: 

Aplet name 

Aplet topic 

Attached library 

Plot view procedure pointer 

Symbolic view procedure pointer 

Numeric view procedure pointer 

I'll ii setup view procedure pointer 

Symbolic setup view procedure pointer 

Numeric setup view procedure pointer 

Note view procedure pointer 

Sketch v iew procedure pointer 

Xmin variable 

Viuin variable 

( )lher slian-d variables 



• Aplet-specific variables 

• List of symbolic expressions 

• Array of independent values for numeric view 

• List of strings for custom views 

• Note text 

• List of graphics objects for the sketch view. 

For aplets built into the HP 980, pointers like the plot view 
procedure pointer refer to code built into the 512K-byte R< >M 
New aplet types can include a RAM-based support library 
containing new view procedures. All aplets must contain a 
basic set of variables, but specific aplet types may implement 
additional optional v ariables. 

Mew Structure 

Bach aplet view is managed by the topic outer loop, typi- 
cally with the help of graphical user interface (GIT) tools 
like input forms. To customize its behavior, a view (or its 
GIT helper) specifies objects that are used while the view is 
visible. These include the view entry and exit handlers, the 
display handler, and the key handler, among others: 

• Initialization procedure pointer 

• Exit procedure pointer 

• Display procedure pointer 

• Key handler procedure pointer 

• Non-view-specific-key -alio wed flag 

• Softkey menu description 

• Error handler. 

Symbolic View 

Normally, the symbolic view is the defining view for an 
aplet. When the user starts an aplet. its symbolic view will 
be shown so the user can enter symbolic expressions or 
equations to be used in the aplet. 

The symbolic v iew is the generalization of the IIP 48G/GX EQ 
list. The EQ variable on the HP 4.8G is a list of unnamed sym- 
bolic expressions, which are plotted and traced together. 
The HP 38G breaks this into individual named symbolic ex- 
pressions that have independent check marks. Expressions 
for a parametric function are further broken into real and 
Imaginary parts. The expression for a sequence is broken 
into two initial terms and a reclusive relation. Tills simplifies 
editing and selection of symbolic expressions ( Jiving ex- 
pressions names in the symbolic view allows them to be 
reused in other expressions, home calculations, and pro- 
gramming. 

Expressions entered in the symbolic view are checked for 
syntax errors and to a limited extent for semantic errors. 
Expressions defining a sequence are further classified and 
transformed into an internal form for cache-based iterative 
evaluation, saving both lime and run-lime RAVI Space, An 
EVAL menu key is provided in the symbolic view for c onstant 
expression evaluation, expression simplification, and function 
unfolding. Fig. 1"> shows how the Fibonacci sequence can be 
defined and checked using ten keystrokes. (The EVAL menu 
key is shown when a command line is not active. It appears 
where OK appears in Fig. 15.) 

The generic symbolic view is based on the choose box en- 
gine, which lakes over display handling to maintain check 
marks on the left of the screen and takes over key mapping 
for dynamic menu changes and editing of expressions. 



© Copr. 1949-1998 Hewlett-Packard Co. 



Jum 1888 Hewtea-Packanl Journal 91 



SEQUENCE SYMBOLIC MEM 

U 1 -:: 1 > = 1 

Ul(2) = l 



UKN) = 



U2<1>= 
U1CN-D-HJ1CN-2H 



Fig. 15. I 'sing llif symbolic view of I lie sequence aplet. I lie 
Fibonacci sequence can lie defined and cliecked using l.en 
keystrokes. 

Because of the different requirements lor different aplets, 
the generic symbolic view is implemented as a derived in- 
stance of the symbolic view with several data fields and 
virtual routines lo be overridden. The information fora sym- 
bolic view includes: 
C ombine factor 
Total expression 
Group size 
Single-pick flag 
Soft key menu description 
Edit menu description 
Move focus procedure pointer 
Special initialization procedure pointer 
Edit terminator procedure pointer 
Expression checker 
Poststore procedure pointer. 

For example. I he sequence aplet combine factor is 3 (three 
terms define one sequence). The total expression is 30 (up 
to 10 sequences allowed). The group size is 3 (every three 
terms will share one check mark). The edit terminator pro- 
cedure transforms definitions into internal form. The move 
focus procedure updates menu soft keys with the current 
sequence name. The expression checker rejects list or ma- 
trix expressions and initial terms that depend on the se- 
quence independent variable n. 

The symbolic view for the statistics aplet posed a new 
problem because we decided to show two expressions on 
one line, one for data and one for frequency, which is not 
.supported by the choose box engine. The statistics symbolic 
view is implemented by customizing the input form to mimic 
a scrollable choose box with a check mark and two columns 
of data. 

Setup Views 

After expressions are set up. setup views are the natural 
places to go for setting the parameters for further explora- 
tions. The plot Setup view is the main setup view, similar to 
the plot dialog box on the HP48(i. but enhanced with wider 
fields and a double-page design. The plot setup view, the 
symbolic setup view, and the numeric setup view are all 
based on the input form engine. 

Plot View 

The plot view is the most complicated of all aplet views. 
Students will spend most of their time here exploring the 
behavior of curves graphically and interactively. 
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Fig. 16. Box and whisker plot 

The IIP38G takes the DRAW command in the HP IKG/GX plot 
window and improves it by implementing a "smart redraw." 
When switching back from other views, the picture, cursor 
position, and display mode are restored to the same state 
instantly, except when the defining parameters are changed. 
Plotting c an be stopped and resumed later. When the user 
tries to move the cursor beyond the screen boundary, the 
graph shifts and redraws the scrolled-in portion. Zoom 
options are put into a choose box with more descriptive 
names. Instead of taking the current point as the first point, 
the box zoom prompts the user to select the first point. 
Tracing is improved and extended to statistics plots. Fig. 16 
shows tracing on box and whisker plots. 

For the function aplet. more areas of exploration are sup- 
ported through the FCN menu key, which displays a choose 
box with choices of root, intersection, slope, area, and ex- 
tremum. Fig. 17 shows the display for an area computation. 

The plot view has overridable routines for curve drawing, 
curve tracing, FCN key handling, DEFN key handing, and other 
functions. For example, the function, parametric, and polar 
aplets share the same plot loop with different preprocessing, 
but the sequence aplet uses another plot loop for handling 
the discrete independent variable n. 

For tracing, the sequence aplet implements four-way scrol- 
ling: the screen will scroll when the cursor is moved off- 
screen in all directions. The scatter plot overrides the FCN 
menu key to calculate and display a data-fitting curve. The 
Information for a plot view includes: 

• Draw procedure 

• Independent variable ID 

• Softkey menu description 

• Display procedure pointer 

• Key handler procedure pointer 

• Pointer display procedure 

• Draw axes Hag 

• Draw grid flag 
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Fig. 17. Area computation inressiMc via the FCN soflfc. > 
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Fig. 18. Automatic numeric view. 
Axis labels 

Display coordinate procedure 
Tracing procedures 
Coordinate display procedures 
Equation display procedure. 

Numeric View 

The numeric view lets a student explore the functions defined 
in the symbolic view in numeric form. The leftmost column 
displays values of the independent variable ( except for sta- 
tistics) and adjacent columns represent function results. 
There are two basic forms of the numeric \iew: automatic 
(Fig. 18) and build-your-own (Fig. 19). The automatic view 
displays a series of independent values with a starting value 
and a step specified by either the numeric setup view or the 
variables NumStart and NumStep. 

The BIG menu key lets the student display the numbers using 
a larger font. The ZOOM key provides a series of options for 
changing the start and step values for the independent vari- 
able display. 

When the cursor is moved lo the upper or lower boundaries 
of the display the table scrolls to show acUacent values. The 
table can also be resel by entering a new value for the inde- 
pendent variable in the leftmost column. 

The build-your-own numeric view is useful for creating a 
table of interesting values. The values for the independent 
variable column in the build-your-own numeric view are 
accessible via the Numlndep variable. 

The information for a numeric view includes: 

Initialization procedure pointer 

Numeric zoom choices 

Softkey menu description 

Display procedure pointer 

Key handler procedure pointer 

Split plot-table configuration information. 




Fig. 20. Plor-tabl.' view. 
Plot-Table Mew 

The split plot -table view allows a student to combine the 
plot and numeric views (Fig. 20). 

This view is implemented primarily as a plot view, with the 
right side of the display being a small numeric view that 
updates to reflect the position of the plot cursor. As the 
student moves the cursor from one function to another, the 
right side of the table changes to reflect the function being 
traced The DEFN menu key displays the current function at 
the bottom of the display. This lets the student display the 
symbolic, plot, and numeric views of a function all at once. 

Note View 

Besides main aplet views like plot view, symbolic view, and 
so on. auxiliary views like the note view and sketch view are 
provided to add textual and pictorial descriptions to an aplet. 
The note view (Fig. 21) can be used to edit and display a 
text string attached to an aplet. The note can provide infor- 
mation about the aplet's subject, a suggested sequence of 
exploration, or the supported keys. The note view is basically 
a word-wrapping text editor with a G-line-by-22-charaeter 
display. 

Although the original HP 48G/GX edit line supports multiple- 
line editing, individual lines are handled independently. 
When more than 22 characters are inserted into a line, Ihai 
line gets scrolled lo the left without affect ing the rest of the 
lines. The HP38G note view Ls implemented independently 
from the edit line code. Direct display routines are coded lo 
show a character or a string at a specified location without 
generating intermediate GROBs. System-level keyboard han- 
dling code is modified to implement a general blinking cur- 
sor display scheme. Besides the text string lo be edited, the 
note editor maintains a linewidth array for word-wrapping 
bookkeeping. 

Icontmued on page 551 
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Distributed Software Team 



The HP 386 calculator was the first product to be developed by Hewlett- 
Packard's Asia Pacific Personal Computer Division after the charter for 
handheld products was transferred there from Corvallis, Oregon The 
software team was split between Oregon and Singapore, so we learned 
to make good use of communication technology, including Internet tools 

We had to figure out how to overcome a separation of over 9,000 miles 
and eight time zones. At the end of normal working hours in Oregon, the 
Singapore workday has just begun Our specific communication needs 
included same-time, different-place meetings and documents that could 
be accessed anywhere, anytime. 

Same-Time, Different-Place Meetings 

Two of our Oregon team members were already experienced telecom- 
muters, working at home a few days each week. They pioneered the idea 
of "virtual team meetings." Our first virtual meeting experiments were 
practiced with everyone in the office, sitting in our individual work areas 
with telephone headsets and a shared window running on all of our 
computers, so that we could all view and edit the same document at the 
same time. 

We were able to work out the initial kinks in the process by standing up 
and shouting to each other if necessary The next step was to link our 
two telecommuters from their Oregon homes. When we added our two 
Singapore engineers, we were already familiar with the procedures and 
etiquette for same-time, different-place meetings. 

The team used HP 9000 workstations as well as computers at home that 
were connected to the workstations in the office using a LAN connection 
over 56-kbit/s frame relay lines. The applications used for sharing docu- 
ments during meetings ran on our workstations and included Collage and 
HP SharedX These applications allow a group of people to view and edit 
the same document simultaneously. However, our more typical way of 
sharing documents during meetings was by individually accessing our 
team's Worldwide Web pages. 

Anywhere, Anytime Documents 

Project documents are used to keep people informed of discussions and 
decisions and to provide product descriptions for the extended team 
members. Our challenge was to create and maintain project documents 
that would be accessible from many different locations. Our documenta- 
tion process made extensive use of Internet technologies: hypertext 
documents, graphical browsers, and electronic mail 

Hypertext documents contain links to other documents. They can be 
easily created with any text editor using a special kind of formatting 
called Hypertext Markup Language (abbreviated HTML). Our team 
members were all able to get started with simple hypertext document 
creation after only a few minutes of study. 

It became apparent to us that HTML was the best choice for developing 

and maintaining our project documentation, because 

As a text-based source file format. HTML is compatible with our source 

code control system. This allowed us to maintain HTML documents with 

the same familiar tools that we used to maintain source code. 

A variety of HTML browsers such as Mosaic and Netscape are commonly 

available for multiple hardware platforms, which ensured that each team 

member could access our documentation 



• The hypertext nature of HTML documents provided a natural and exten- 
sible means to link together our rapidly growing documentation set 

We started with an HP 38G project home page. It had links to conven- 
tional software project documentation, such as our external reference 
specification (ERSI documents, which were also authored in HTML But 
the power of linked documents to disseminate information also led us in 
new directions that supported the HP 38G project development process 

In past projects, we often regretted our inability to look back at topics 
discussed through less formal means like email, but with our HP 38G 
home page and tools to support HTML document generation, we finally 
had the enabling technologies to overcome this limitation. We began to 
archive our group email discussions and link them into our HP 38G proj- 
ect home page, indexed by date, author, and subject. On frequent occa- 
sions (sometimes as a group during a teleconference) we would refer 
back to these email archives to revisit a line of reasoning about design 
choices. 

The success of the discussion archival technique led to the side benefit 
ol a uniform, centrally maintained mailing list for software team members 
Over time we expanded this concept to include multiple discussion 
groups, each with associated email archives and each specialized for a 
different audience. 

Soon we were using the HP 38G home page to collect information that 
was previously scattered throughout paper documents or engineers' 
minds For the first time, documents detailing the setup of our software 
debugger systems, EPROM burners, and more were readily available 
around the clock 

Other departments involved with the HP 38G began to seek out the re- 
sources we made available through the HP 38G home page, and it was 
quite rewarding for us to be able to direct them to our pages The frustra- 
tion of trying to coordinate delivery of information by hand was becoming 
a distant memory. Some departments, with our encouragement and sup- 
port, began making information available through linked documents. 
These we gladly added to our project page, making it more valuable for 
all parties. For example, when our colleagues in Singapore had industrial 
design drawings to share, these were made available to all through the 
HP 38G home page, and the QA department's software test plans were 
added so that engineers could review and comment on them to ensure 
complete test coverage 

Conclusion 

Our use of linked HTML documents has increased steadily since the HP 
38G project We now have more email discussion groups, our own Web 
server to simplify access for remote connections, a team home page with 
links to all of our project home pages, a dynamic team calendar of 
events, a "what's new" service for quickly learning what's changed, and 
a searching service for finding specific topics amongst our wealth of 
interconnected documents We expect exciting new developments to 
further increase our productivity as we expand our knowledge and use of 
the Web 
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Sketch View 

Some people believe that a picture is worth a thousand 
words, so the HP 38G generalizes the HP 48G/GX's bitmap 
editing features to form an aplet sketch view. With the 
sketch view, the user can edit and display a set of bitmaps 
attached to an aplet. Holding down the page-down or 
page-up key shows a prestored animation sequence 
(Fig. 22). 

Compared with the HP 48G/GX, the HP 38G limits the bit- 
map editing features and improves the user interface and 
implementation. The i!P 38G implements a rubber band 
algorithm when the user drags the second point to define a 
line, rectangle, or circle. The circle drawing code uses a fast 
integer-based iterative algorithm. The user can drag a text 
string in the small or medium font to any location. The HP 
38G can store a selected portion of a screen into a GROB 
variable and recall it. When bitmaps are stored back into an 
aplet directory. I hey are first trimmed to the minimum 
enclosing rectangle to save RAM space. 

Additional Views 

Each aplet type defines additional views available in the 
VIEWS menu. For example, the function aplet offers some 
hybrid \iews and some preconfigured plot views. Fig. 23 
shows the Enaction VIEWS menu. 

In addition, a user can define a new set of special views that 
provide high-level tools for an aplet. Such a custom interface 
makes the aplet easier to explore and hides details of the 
calculator's operation. 
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Fig. 23. Function VIEWS menu. 

The Home Environment 

The freefomt home environment fills the traditional calcula- 
tor role of supporting quick calculations. The user enters 
expressions in algebraic form and the value of the expression 
(usually a number) is returned. 

Unlike aplets. the home environment provides access to all 
calculator resources, including lists, matrices, graphics 
objects, and programs. 

The History Stack 

The text of the input and the result are stored on a history 
stack (Fig. 24a). The user can review the items on the history 
stack and reuse those items as parts of the current input 
(Fig. 24b), Expressions and equations on the history stack 
can be shown in two-dimensional mathematical format 
(Fig. 24c). 
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Fig. 25. Fraction number rorinat. 

The III' 3SG includes special features to help beginners. To 
help students learn about fractions, the HP38G has fraction 
number formal, which uses Continued fractions to convert 
results to rational form (Fig. 25). To help students unfamiliar 
with standard algebraic syntax, the HP 38G attempts to 
interpret ill-formed expressions as implied multiplication 
(Fig. 26). 

The Variable Ans 

Each lime the user inputs an expression, (he value of (he 
expression is stored in a variable named Ans. This current 
value of Ans is placed on the history slack, and the name Ans 
can be used in I he next calculation. Even when the user 
enters a command lhat performs some action bill doesn't 
return a value, the current value of Ans is placed on the 
history stack. 

If the user starts an input with an infix function such as +, -, 
*, or/, the calculator inserts the name Ans first. This saves 
keystrokes for tasks such as balancing a checkbook (Fig. 27). 
If the user presses ENTER without input, the previous input is 
repeated (Fig. 28). This saves keystrokes for iterative opera- 
tions. 

The VAR and MATH Menus 

To organize its extensive resources, the HP 38G presents the 
most-used variables and functions on the keyboard. Addi- 
tional resources are available in the VAR and MATH menus. 
These two-column menus offer specific items in the light 
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Fig. 26. (a) Implied multiply input, (b) Result. 



Fig. 27. Checkbook calculations in the home environment. 

column, categories of items in the left column, and broader 
choices on menu keys. 

In the VAR menu ('Fig. 29) the user can choose to examine 
variables either from the current aplet or from the shared 
home variables. The user also can choose either the name or 
I he value of a variable. 

In the HP 38G most variables are strongly typed, that is, for 
many variables the value must be a specific- type. For exam- 
ple, the variable X must contain a real number, Z1 must con- 
tain a complex number, and M2 must contain a matrix. Sev- 
eral classes of variables contain exactly ten variables, such 
as the ten complex variables Z1, Z2, Z9, ZO (Fig. 30). 

variables are used not only for mathematical objects, but 
also for modes. For example, storing the constant Degrees 
(whose numerical value is 1) into the variable Angle selects 
degrees angle mode. 

The classes of home variables include complex numbers (Z1 
to ZO), graphics objects (Gl to GO), aplets (user-selected 
names), lists (L1 to LO). matrices (Ml to MO), modes (fixed 
descriptive names), notepad (user-selected names), pro- 
grams (user-selected names), and real numbers ( A to Z, 9). 

The MATH menu (Fig. 31 ) offers additional functions, com- 
mands, and constants not available on the keyboard. The 
categories of functions are: calculus functions, complex- 
number functions, constants, hyperbolic functions, list 
functions, loop functions, matrix functions, functions of 
polynomials, probability functions, real-number functions, 
statistics functions, functions for symbolic manipulation, 
tests, and trigonometric functions. 

Lists and Matrices 

For these composite variable types there are catalogs that 
report the variables' sizes, along with special editors to enter 
and modify the elements. The catalogs and editors are tasks. 
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input is repeated. This saves keystrokes for iterative Operations. 
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Fig. 29. VAR menu of the home environment. 

so the user can easily move among aplets, home, catalogs, 
and editors. The list editor (Pig. 32) is one-dimensional- The 
matrix editor is two-dimensional (Fig. 33). 

Lists and matrices can also be used as functions of an index 
value. For example. Ll is a list, while LI 121 is an expression 
whose value is the second element of Ll. 

Notes and Programs 

For these text variable types there are catalogs that show 
the user-selected names and editors that allow freeforni text 
input. The notepad holds simple lext files such as phone 
lists {Fig. 34). 

There is a program with the fixed name Editline. which holds 
the most recent input from the home environment. The user 
can choose to edit the most recent home input from within 
the program editor, or to execute the program Editline from 
the home environment by simply pressing ENTER. 

Programs aren't parsed until the first time they're run. 
Because of this, and because the program editor is a task. 
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Fig. 30. Most variable values must he a specific type and several 
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Fig. 32. The list editor is one-dimensional. 
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Fig. 33. The matrix editor is two-dimensional. 

the user can write a program a little at a time, leaving the 
program in an invalid state between editing sessions. Fig. 35 
shows part of a program. 

Commands that perform some action and return no result 
can appear only within programs ( which includes Editline). 
The categories of commands are: commands to control 
aplets. branch commands, commands for scaled drawings, 
commands to manipulate graphics objects, loop commands, 
matrix commands, printing commands, prompt commands 
for input and output, and statistics commands. 



SS PHONE NOTE*!;* 

filphie 123-4567 



phi 

Betty 
Grandma 
Delia 
4 

■■BUB I 



399-1234 
567-3991 
234-5678 



IEIB9I 



Fig. 34. The notepad holds simple text files such as phone lists 
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Programs that Support Aplets 

The most important purpose of programs in the IIP 38G is to 
support the user-defined entries within the VIEWS menu 
(Fig. 30). Using the SETVIEWS command, the user specifies a 
number of Special views that represent the tools for manipu- 
lating the aplet. These tools can be presented at a high level, 
using terms relevant to the particular aplet and hiding the 
actual methods of the calculator from the aplet user. 

The specification for each special view includes a prompt, 
which appears in the VIEWS menu, ll also includes a program, 
which is run when the special view is selected, and a view 
specification, which determines the standard view (plot, 
symbolic, etc. J to be started when the program is done. 

If an aplet has special \iews with start or reset prompts, 
pressing the menu keys START or RESET within the LIB catalog 
( Fig. 87) automatically selects the corresponding special 
view. 

While the prompt category of commands enables program- 
matic interaction with the user, the main goal of HP 38G 
programs is t o modify the configuration variables of the cur- 
rent aplet. After the program runs, the standard view speci- 
fied in the VIEWS menu starts, operating with the configura- 
tion left by the program. This approach has the adv antage 
that the interface to the standard view is familiar to the user. 
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Fig. 37. LIB catalog, 

All the components needed for special views are automati- 
cally managed by the HP 38G. The menu of special views is 
stored as a part of the aplet, and the programs used by the 
special views are aulomatieally transferred with the aplet. 

This makes aplets simple lo use: a single request gets the 
aplet and associated programs, and the VIEWS menu offers 
the high-level tools that allow the user to focus more on the 
content of the aplet and less on the calculator. 
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Creating HP 38G Aplets 



This article explores a simple aplet and shows how to construct an aplet 
called PolySides. 



by James A. Donnelly 



Iii designing an aplet for llie IIP 38G calculator, its impor- 
tant to remember two guiding principles of the IIP 38G de- 
sign. First, the design recognizes that in a classroom setting 
there Ls (and should be) a large discrepancy between the 
amount of information entered into a graphing calculator 
and the amount of information produced by the calculator. 
We sought to minimize the calculator input required of the 
student and the teacher and maximize the returned informa- 
tion. Secondly, we sought to exclude irrelevant possibilities. 
By reducing irrelevant choices you focus the user's attention 
on the subject of interest and avoid distractions from things 
that don"t matter. Many choices made during the design of 
the HP 38G were based on this goal. 

Aplets contain information and have views. The information 
in an aplet consists of every major piece required to produce 
the views: the equations, setup information, mode informa- 
tion, sketch or text annotations, and attached libraries or 
programs. In this article we'll explore a simple aplet, then 
look at an aplet called PolySides and examine how it was 
constructed. 

Using Built-in Aplets 

When the IIP 38G is firsl turned on. the built-in aplets are 
empty. There's no equation, note, or sketch. When the user 
adds this information, Ihese aplets come alive. You can save 
an aplet at any time, so it's easy to start one project, change 
in midstream to another, then come back to Ihe first. 
( Because the appearance of the screens depends on the 
information you enter, the screens on your calculator may 
look different from the example screens in this article.) 

A simple way to illustrate the aplet concept is lo explore the 
equation SIN(X 2 I/X. Select the function aplet, press SYMB, and 
enter the equation. • 
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Now press PLOT to see the plot using the default plot 
parameters. ♦ 
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Use the box option under ZOOM to look at a smaller area of 
the plot. ♦ 
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You can see the plot scale by pressing [shift ]PL0T to see the 
plot setup view. ♦ 
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At this point, you have an aplet that's completely dedicated 
In your interest in Ihe function SINIX 2 I/X, and the aplet can be 
saved under a unique name or transmitted to another IIP 
MSG or a computer. When the aplet is restarted 00 the origi- 
nal or another IIP :!S(i. ;ill modes and scales are set just Ihe 
way lhc\ were saved. 
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Exploring the PolySides Aplet 

The PolySides aplet is designed to explore how a regular 
polygon can approximate a circle as the number of sides 
inc reases. PolySides can be loaded from a disk or another 
HP 38G in a single operation from the LIB catalog. Once 
loaded. PolySides appeals in the aplet library. ♦ 
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We are now just a single keystroke away from exploring the 
aplet. To begin the exploration, press START. The motivation 
for the lesson is displayed first. ♦ 



Explore how a regular 
polygon begins to 
approximate a circle 
as the number of side; 
increases. 

Press any key,., 



After the introduction has been read and a key pressed, the 
next step is to enter the radius of the circle to be approxi- 
mated. » 
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After the radius has been entered, the properties of t he 
circle are displayed. » 
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After the circle properties have been viewed, the note view of 
the aplet is displayed. The PAGE menu key switches between 
the pages "I the note » 
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lb see a sketch of the problem, press SKETCH. 
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So far we have seen a pretty complete summary of the lesson 
with less than a dozen keystrokes. Now we can begin to 
explore how may sides are needed to approximate a circle. 

Our central point of departure for PolySides is VIEWS (as 
mentioned in the note view). ♦ 
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These choices let you determine w hat aspect of a polygon 
approximation to a circle you'd like to explore. To explore 
how the perimeter of the polygon approximates the circle, 
move the highlight down to Perimeter and press OK. The plot- 
table view is presented automatically. ♦ 
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This is one of the HP 38G"s split views, showing the plot anil 
numeric views of the perimeter approximation at the same 
time. The variable X represents the number of sides, and the 
equation stored in F2 returns the perimeter as a function of X. 
Pressing the left or right arrow key moves the cursors for the 
plot and numeric views simultaneously. When the cursor is at 
the left edge of the plot, the table on the right shows the rapid 
change of the perimeter from a triangle to a nonagon. ♦ 
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To see the equation, just press SYMB. » 
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The symbolic view is where aplel equations are stored. The 
check mark beside F2 indicates that when a plot or numeric 
view is displayed, F2 will be used. Another view of the equa- 
tion is available by pressing SHOW. » 




Notice that after the introduction there is no Fixed order of 
events. You can change to any of the views at any time or 
press HOME at any lime to do a short calculation. Part of the 
design philosophy of aplets is to let the student explore the 
lesson at will, without following any particular algorithm. 
( )nce you've explored the approximations to the perimeter 
and area, and perhaps explored the effect on side lengths. 



you may decide that a polygon with 57 sides yields a fair 
approximation to the circumference of a unit circle. ♦ 
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Now you can look at a summary of a 57-sided polygon by 
selecting Polygon Props ( for polygon properties) from the VIEWS 
choices • 
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Perimeter 
Rrea 


..' 

7R3b 
7R51 
7RbH 

ZRB^ 


Polygon Props 


Bull 


LMI iM EHHJ 1 


DK ||| 



Press OK to select this choice. Since the cursor was last on X 
= 57, the number of sides defaults to ">7. ♦ 



Wi. NUMBER OF SIDES W$$$$8$& 



SIDES 



ENTEF; NUMBER OF SIDES 



After the user accepts ( or alters) the number of sides, the 
polygon data is displayed. ♦ 



57 Sided Polygon 

flppr ox i mat i ng c ircle 
of radius 1.00 
Side length= 6.11 

Press any key.,. 



57 Sided Polygon 

Polygon per i meter = 
6 . 28 

C i rc 1 e c i rcumf erence= 

6.2S 
Press any key... 
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57 Sided Polygon 

Polygon area= 

Circle area 85 

3. 14 
Press any key- 



Now we've observed I hat a 57-sided polygon does a fair job 
of approximating a unil circle. More explorations are pos- 
sible. For instance, if the circle lias a very large ratlins, how 
many more sides are required for a polygon lo closely 
approximate the circle's area? 

Alter I lie lasl polygon property screen has been acknowl- 
edge! I xviih M keystroke, the VIEWS menu is displayed. » 



Start 



Side Lengths 
Per i met er 
Rrea 

Po 1 ygon Props 



IHEH1I 



This lets you start wit h anol her circle or go back lo find a 
differeni approximation. 

Notice thai the keystrokes involved for the entire exploration 
have been oriented to (he views. We haven't entered a single 
bit of setup or scaling information beyond the radius of the 
circle being approximated, litis is the goal of a well-formed 
aplel; more attention is directed lo the lesson and less atten- 
tion is directed to the mechanics of I he calculator. You can 
imagine a teacher distributing Ibis aplel in a classroom for 
part of a day's lesson. 

If you're familiar with Hie HI' 48(i/GX calculators, you'll 
notice that variables like EQ and PPAR have never been men- 
tioned, even though we changed the equation anil plot scaling 
parameters several limes. Furthermore, we never went near 
an input form lo set the scale manually (although we could 
have done so by pressing | shift] PLOT to display the plol setup 
view). 

Building the PolySides Aplet 

PolySides was constructed using the function aplet and five 
user programs attached with Ihe SETVIEWS comnuind. 

Beginning with a reset function aplet. the equations, note, 
and sketch were entered directly on the calculator. The 
equations are: 

Side Length fkx)=2*r*sin(180/x) 
Perimeter F2 (x) =x*2*r*sin( i80/xi 
Area F3 <x) = . 5*x*r 2 *sin( 360/x) 

Then five programs were entered, one for each entry in 
VIEWS. After Hie programs were entered, they were attached 
to the aplet with Ihe SETVIEWS command. For convenience 
during aplet dev elopment, a separate program. SetPolyViews, 



was entered that contains Hie SETVIEWS command. SETVIEWS 
allow s you lo customize (be VIEWS key with your own entries 
and selected entries from Ihe default VIEWS choices. SETVIEWS 
takes triplets of arguments. Each triplet contains the prompt 
lhat will appear in the VIEWS list, a program name, and a 
number corresponding lo the v iew that should be displayed 
after Ihe program is executed. The SETVIEWS command for 
PolySides looks like this: 

SETVIEWS 

"Start Poly 1"; 8; 
"Side Lengths" ; " . Poly2" ; 16 ; 
"Perimeter" ; " . Poly3" ; 16 ; 
"Area"; " . Poly4" ; 16 ; 
"Polygon Props" ; " . Poly5" ; 7 ; 

When Side Lengths is selected, the program Poly2 is executed, 
then view number lb is displayed. View number 7 is the VIEWS 
list, view number 8 is the notes view, and view number lb is 
the split plot-table view, A SETVIEWS convention is that if a 
prompt is [tamed Start or Reset it is associated with Ihe START 
or RESET menu key in the LIB catalog. The PolySides aplel 
takes advantage of this feature so that pressing START in the 
LIB catalog gets a student underway in a single keystroke. 

The programs are listed below. (Note thai the translation 
codes used are lite same as translate code 3 on the HP 
48G/GX.) 



Polyl (Start) 

ERASE: 

DISP 1; "Explore how a regular": 

DISP 2 ; "polygon begins to": 

DISP 3 ; "approximate a circle": 

DISP 4; "as the number of sides" 

DISP 5 ; "increases ." : 

DISP 7; "Press any key...": 

FREEZE: 

IF R\< = 0 THEN 1\|>R END: 
INPUT R;"SET CIRCLE RADIUS"; 
" RADIUS:"; 

"FIRST ENTER THE CIRCLE RADIUS 
ERASE: 

2\l>Digits: Fixed\ I >Format : 



Clear tin- display 
Display the 
motivation for 
ihe aplel 



DISP 1;" Circle Properties": 

DISP 3; "Radius = " R: 

DISP 4 ; "Circumference = " 
DISP 5; "Area = " \pi*R»2: 
DISP 7; "Press any key..." 
FREEZE : 

Standard\ I >Forntat : ERASE 



Prompt for the 
Circle radius 

R: 

Clear the display 
Set rix J display 

mcidr 

Display the screen 

lillr 

Display ( ocii 
property 

2*Vpi*R: 



Wait for a key 
press 

Restore standard 
display format, 

( tear tin- display 



Programs Poiy2 through Poly4 do similar jobs. Each validates 
the value for R (the radius), selects the appropriate equa- 
tions in the symbolic view, calculates the plot scale parame- 
ters, and sets the initial values for the numeric view. Note 
that the plot scale is calculated to fit above the menu. The 
menu occupies 1/S Ihe display, so an adjustment of 1/8 the 
calculated vertical range is made to the vertical scale. 
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Poly2ISide Lengths) 

IF R\< = 0 THEN 1\I>R END: 

CHECK 1: 

UNCHECK 2: 

OTJCHECK 3: 

3 \ I >Xmin : 

67\ I >Xmax: 

Fl(Xmax)\l>Yniin: 

Fl (Xmin) \ I >Ymax: 

Ymin- . 125* (Ymax-Ymin) \ I >Ymin: 

3M >NumStart: 



1\ I >NumStep: 

Poly3 (Perimeter) 

IF R\<=0 THEN 1\I>R END: 

UNCHECK 1: 

CHECK 2: 

UNCHECK 3 : 

3\ I >Xmin: 

67 \ I >Xmax : 

F2 (Xmin) \ I >Ymin: 

F2 (Xmax) \ I >Ymax: 

Ymin-. 125* (Ymax-Ymin) \ I >Ymin: 

3\ I >NumStart: 

1\ I >NumStep: 

PolyKArea) 

IF R\<=0 THEN 1\I>R END: 

UNCHECK 1: 

UNCHECK 2: 

CHECK 3: 

3\ I >Xmin: 

67 \ I >Xmax: 

F3 (Xmin) \ I >Ymin: 

F3 (Xmax) \ I >Ymax: 

Ymin- . 125* (Ymax-Ymin) \ I >Ymin: 

3\ I >NumStart : 

1\ I >NumStep : 

Poly5 (Polygon Properties) 



Ensure a reason- 
able value for R 
Select equation Fl 



Set the plot scale 



Fit the plot above 
the menu 
Set the numeric 
view to begin at 1 
and increase in 
steps of 1 



Select equation F2 



Select equation FS 



INPUT X; "NUMBER OF SIDES" ,- "SIDES" ; "ENTER NUMBER 


OF SIDES";X: 


Sides prompt 


ERASE: 


Clear the ilis/ilui/ 


Standard \ 1 >Format : 


Set standard 




format 


DISP 1,-" " X " Sided Polygon": 


Display the screen 




title 


2\l>DigitS: Fixed\ 1 >Formac : 


Set FIX 2 format 


DISP 3; "Approximating circle": 


Display circle 


DISP 4; "of radius " R: 


radius and poly- 


DISP 5,-"Side length= " FKX): 


gon side length 


DISP 7; "Press any key...": 




FREEZE: 


Wait for a key 




press 


ERASE : 


Clear the display 


Standard\ 1 >Format : 


Set standard 




formal 


DISP 1;" " X " Sided Polygon": 


Display the screen 




title 



Fixed \ I >Fonnat: 

DISP 3 .-"Polygon perimeters": 

DISP 4. " ■ F2(X) : 

DISP 5. -"Circle circumferences 

DISP 6,-" " s*\pi*R: 

DISP 7 .-"Press any key...": 

FREEZE: 

ERASE: 

Standard\ I >Format : 



DISP It 4 



X " Sided Polygon" 



Fixed\ I >Format : 

DISP 3; "Polygon area=": 

DISP 4;" " F3(X) : 

DISP 5; "Circle area=": 

DISP 6;" » \pi*R*2: 

DISP 7;"Press any key..." 

FREEZE: 

StandardN I >Format: ERASE 



Set FIX S format 

Display the 
perimeter and 
ci itu inference 



Wait for a key 
press 

Clear I he dismay 
Set standard 
format 

Display the screen 
title 

Set FDi 2 format 
Display the area 



Wait for a key 

press 

Restore standard 
display format, 
clear the display 



Building Your Own Aplets 

Your own aplets can be as simple as the first example, 
somewhat more involved (like the PolySides aplet). or very 
involved, with more complex user programs. Creating a new 
base aplet that can be downloaded into the HP 38G requires 
the use of System RPL programming beyond the built-in 
user programming language. 

Basic Steps. The basic steps for building an aplet are: 

• Pick an appropriate buill-in base aplet — function, polar, 
parametric, etc. 

• In each of the views, enter the information thai applies. 
FOr instance, you would put your equal ions in the symbolic 
view, plot parameters in the plot setup view, and so on. 

• Put a sketch of the problem in the sketch view and a 
description of the problem in the note view. 

• For a fancier aplet, use SETVIEWS to attach user programs to 
the VIEWS key. Remember that il may be handy to have a 
separate program that stores the SETVIEWS rommand while 
you're developing the aplet. 

Flow of Control. In general, the user of the aplet should deter- 
mine the flow of control, so that a problem can be explored 
freely. The PolySides aplet provides a little extra guidance 
by using Ihe program Polyl attached to the start prompt in 
VIEWS. Polyl displays an initial screen, prompts for the circle 
radius, displays the circle's properties, and finally exits lo the 
note view as directed by the SETVIEWS command, hi general, 
the user should be able to navigate freely among the choices 
in VIEWS or the various views, or go home and come back. 

Shared Variables. The global variables A to Z. Zl to ZO, and so 

on are not stored within an aplet, so if an aplet depends on 
the value of a global variable it's a good idea to have the 
program associated with Start in VIEWS set these values. 
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HP PalmVue: A New Healthcare 
Information Product 



The HP PalmVue system integrates personal computer, alphanumeric 
paging, and palmtop computer technology into an effective solution for 
delivering timely and high-quality patient data to mobile physicians. 

by Edward H. Schmuhl, Allan P. Sherman, and Jon D. Waisnor 



The HI' PalmVue system (IIP M1490A) is a new offering 
from HP's Medical Products Group that allows transmission 
of clinical patient information to HP palmtop computers via 
conventional alphanumeric paging systems. This system 
integrates sev eral forms of current technology, including 
computer net works, palmtop computers, paging systems, 
and devices to deliver a powerful new capability to hospitals 
and physicians who use HP monitoring systems and cardio- 
graphs. This article will provide an overview of the operation 
of the PalmVue system and show how the system integrates 
several components lo deliver this new service to clinical 
users. 

The User Need 

It's Saturday evening, and Dr. Ikeda is enjoying a rare dinner 
out with his spouse and another couple. As chief cardiologist 
of the Memorial Medical Center, he does not get much time 
to relax. This evening, he has lar gely been able to put out of 
his mind the unstable condition of Frank Nielsen, a patient 
under his care in the Memorial cardiac care unit (CCU) who 
is recovering from a recent heart attack. Suddenly, the waiter 
taps him on the shoulder and informs him of an important 
telephone call. He goes to the phone, to be told by Laura in 
the CCU that Frank has developed a very irregular heart 
rhythm and she is very concerned about his condition. Since 
he always carries his portable computer and modem card, 
he suggests that Laura send him a fax of Frank's ECG so 
that he can assess the clinic al situation himself. He goes to 
get his computer, and finds his way to a telephone jack that 
the restaurant has allowed him to use. After several failed 
attempts, he finally gets the faxed ECG transmitted to his 
laptop computer. He is able to tell from the fax that Frank is 
in no immediate danger, but cannot read the ECG well 
enough to make a dear diagnosis. He tells Laura that he will 
quickly finish his dinner and stop by the CCL" on his way 
home. 

It happens that Dr. Washington, another local cardiologist, is 
also out with his family celebrating a birthday at the same 
restaurant. He has several patients in the CCU at St. Francis 
Hospital. As he is about to enjoy his appetizer, he hears the 
familiar sound of a paging alert from his pocket computer. 
He removes his HP palmtop computer from his pocket, waits 
a moment until the computer displays the HP PalmVue index 
screen, and presses a key to display the message. It is a mes- 
sage from Tony in the CCU. Dr. Washington's cardiac patient 
Olga Smetana has been having an increased number of pre- 
mature ventricular contractions (PVCs). and they seem to 



him to have changed shape. Tony's message says he needs to 
know if a change in dosage, or perhaps a new medication, is 
needed. Dr. Washington pushes another key and views Olga's 
ECG waveform in a crisp and detailed display on the palm- 
top screen. He can easily see that the PVCs are not really 
clinically different from those he lias been seeing in Olga's 
ECG for the past few days. He pulls out his pocket-sized 
cellular phone, calls Tony in the unit and tells him that 
everything is OK with Olga, and he will check on her in the 
morning. He then proceeds to enjoy the rest of his dinner. 

HP PalmVue System Description 

The HP PalmVue system integrates personal computer, 
alphanumeric paging, and palmtop computer technology 
into an effective solution for delivering timely and high- 
quality patient data to mobile physicians (see Fig. 1). The 
dispatch station PC handles acquisition of the clinical pa- 
tient data. It also runs the user application to review and 
select the data, converts the clinical data to paging mes- 
sages, and sends these messages to a commercial paging 
system through a modem connection. The HP PalmVue 
critical care system acquires patient data (such as patient 
waveforms and vital signs ) from the HP CareNet monitoring 
network via the SDN interface card. For the HP PalmVue 
ECGstat application, the patient's 12-lead electrocardio- 
graphic signals taken by an HP cardiograph are transferred 
to the dispatch station PC via flexible disk. 

The paging messages travel through the paging system in 
exactly the same form as a typical "call me at 301-457-8438" 
paging message, except that each message consists of a 
string of up to 230 meaningless characters. Most of the major 
paging providers (radio common carriers) send these pages 
from then paging system computers ( known as switches) to 
a satellite uplink. The satellite retransmits the messages 
through a downlink to ground-based paging transmitters in 
the geographical area covered by the subscriber's paging 
service arrangement. This coverage territory may be a met- 
ropolitan area, a region, or an entire country. The transmit- 
ters broadcast the signals, which are then received by the 
pager. 

The paging receiver used in the HP PalmVue system is a 
device called a NewsCard. provided by Motorola. This de- 
vice combines the radio circuits from a standard pager with 
processing, memory, and a PCMCIA (Personal Computer 
Memory Card International .Association) interface. The indi- 
vidual paging messages are transferred to the HP 200LX 
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Central Monitor 
with 
Arrhythmia 




HP CareNet Monitoring Network 

• Shares patient data among patient 
monitors and other srstems including 
PalmVue 

• Supports up to 2 networks. 24 beds 
maximum 




Patient Telemetry 
Monitors 



Scrambled 

Messages Telephone 
System 
Connection 



Paging Service Provider 

• Radio Common Carrier (RCCI 

• Private Carrier 

• In-House Paging Service 




Sends selected 
patient data to any 
medical palmtop. 



Transmitter 



To Pager 



Dispatch Station 

• Patient Selection 
■ Data Review 

• Message Text Entry 

• Select recipient. 

• Initiate transmission to 
paging service provider 

• Connects up to 100 palmtop PCs. 



Built-in Modem 



Medical Palmtop Computer 

• Translers data from pager. 

• Displays patient data/notes 



ft. I' V -V -T-H 



POCSAG 
Protocol 




Pig. l. ill' M1490A PalmVue system. 



palmtop Computer by ;i software program developed by IIP 
for use in Hie III' starhink paging service. If the NewsCard is 
plugged LZltO the palmtop when an IIP PaUTlVue message 
arrives, the palmtop turns on and the messages are automat- 
ically transferred into ihe memory t>l (he palmtop It t ( n ■ 
Ni'vvst lard is not plugged in, the messages are transferred 
later after Ihe user plugs in Ihe card and turns on Ihe palm- 
lop. 

The heart of the IIP PalmVue system is the software. The 
program in the dispatch station P( ' compresses Ihe complex 
patient data, transforms it into a series of short, character- 
based messages, and semis them to ihe paging service. The 
palmtop software processes Ihe paging messages lo recon- 
struct the patient data, and handles Ihe user inierface and 
display of the patient data on the palmtop screen, liefer to 
"I lata Through Paging Technology" on page liS for details of 
the packelizing and reconstruction process. 



The IIP PalmVue Critical care application provides a snap- 
shot of the current patient data as acquired from Ihe IIP 
patient morutor through ihe HP CareNet This data may con 
sisl of a l- r )-second waveform snapshot 'typically the ISCCr, 
used lot assessing ihe patient's heart rhythm), up to three 
"i-second snapshots of other physiological waveforms (blood 
pressure waveforms or other measurements i. and Ihe lull set 
of vital signs (heart rate, blood pressures, etc.). The user at 
(he dispatch station selects the patient data, reviews it on the 
PC screen, and freezes a particular snapshot of information 
for transmission to the remote physician. The user can also 
enter a text note to explain particular concerns or provide 
additional data to the physician. After choosing the recipient's 
name, the user initiates the transmission of the message. An 
example of Ihe user screen on Ihe dispatch station is shown 
in Fig. 2. 
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Main Menu Content Actions Patient List 



II 



15:11 
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ABP 
I8Q 



15:11 



CVP 
30 



15:11 



Note 



Vitals 



HR 111 
PULSE 141 
ABP 134/75(991 
CVP (10) 
PAP 34/17(24) 
Sp02 97 



CVP up from 5. 


Bi lateral 


rales and 


rhonchi. Lasix 


ZOmq. IV 


push as 


ordered without 


response. 




Please advise. 







Patient Note 



Waves < Holt? 



Rhythm i Note 
Waves+Rhy.+Note 



Unlreeze 
Transmission Progress 
Send 



Dr. Washington 



TX Successful 



02-14-1996 15:11:09 



Fig. 2. An example of Che user 
screen on the dispatch station FGi 



The operation of the HP PalmVue ECGstat application is very 
similar, except that a previously acquired patient EGG is read 
in from a flexible disk (or it may have been previously Stored 
in the dispatch station PC). 

Operation of the palmtop application is designed to be as 
simple and intuitive as possible. If the NewsCard is plugged 
into the palmtop when a new HP PalmVue message arrives, 
the palmtop turns on. automatically transfers the paging 
messages into the palmtop, and executes the application 
program. This program reconstructs the patient data file and 
shows the index screen on the display with the new message 
highlighted (see Fig. 3). The user simply presses Enter, and 
the first screen of the new IIP PalmVue message appeal's on 
the palmtop display (see Fig. 4). This screen provides patient 
identification, the time the data was taken, and the text note 
as entered by the sending clinician. The user can access the 
clinical dala portion of the message by using the function 
keys. For example, pressing f5 Vitals brings up the patient's 
vital signs (see Fig. 5). The 15-seeond ECG waveforms can 
be accessed by pressing t6 Rhythm (see Fig. 6). Other portions 
of the patient data file, or alternate \iews such as expanded 
waveform time scales, are similarly accessed by using the 
function keys. Again, the palmtop application for display of 
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a patient's 12-lead ECG operates in a very similar fashion, 
with display formats tailored to useful presentation of the 
12-lead waveform and diagnostic information. 

HP PalmVue Architecture 

Several key objectives drove the architectural design of t he 
HP PalmVue system: 

Allow independent development and testing of the dispatch 
si;it ion and palmtop portions of the HP PalmVue software. 
Allocate processing tasks appropriately to the dispatch 
station and the palmtop. 

Leverage existing software for the critical care application. 
Isolate the transmission process as a subsystem to minimize 
regulatory concern about the specifics of the paging infra- 
structure. 

Develop the key software modules in the PC and palmtop to 
be independent of the paging technology to allow a smooth 
transition to alternate wireless communication technologies. 

The resulting architecture provides a good solution that 
meets these goals and allowed for a smooth development 
process. 



Fig. 3. Index screen on the palmtop display with llie new message 
higltlighled. 



Bed 11 Maria Lopez 14-Feb 15:11 

Mem Med Ctr 300-293-5295 

From: Sarah Putnam 
To: Dr. Washington 

— — — — — — — — — — — —— Sender Note — — — — — — — — — — 

CUP tip rrom S. Bilateral rales and 
rhonchj . L.asix 20ms. push as 

ordered without response. 

Please advise. 



Fig. 4. When the- user presses Enteral the index screen, the first 
screen of the new HP PalmVue message appears on the palmtop 
display. 
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Fig. 5. Pr.-ssmji BVitaJs brings up the patient's vital signs 

The HP PalmVue sj'stem architecture is shown in Fig. 7. The 
key to achieving many of the design objectives is the clinical 
message file. This file is a specially defined representation 
of the clinical patient data, together with appropriate identi- 
fication and control information. It exists in the system as a 
standard DOS binary file. This allows the clinical message 
files to be created, edited, and transported using conventional 
PC tools. The clinical message file is provided as input to 
the transmission process within the dispatch station PC. and 
is reconstructed within (lie palmtop software. 

This design greatly facilitates testing. Each application sub- 
system can be tested and verified independently by either 
evaluating the clinical message file as output from the PC, or 
by providing a Valid clinical message file as input to the 
palmtop. The entire software system can be tested without 
any use of the wireless communication subsystem. 

This design also resulted in optimized system performance. 
The bulk of the processing load, w hich is the transformation 
of waveforms into scaled display data, is handled in the dis- 
patch station PC. The scaled waveform data that the palm- 
lop receives in the clinical message file requires very little 
processing to display on the palmtop screen. 

The inclusion of explicit error codes in the clinical message 
file allows the verification of data integrity with total inde- 
pendence from the transmission subsystem. This allowed 



Fig. 6. The lo-sccond ECG waveforms can be acre-ssed by pressing 
rS Rhythm. 

the regulatory concerns for data integrity to be addressed 
without consideration of the specific performance charac- 
teristics of the paging systems. Both the clinical message 
file-based architecture and the error code implementation 
are capable of transparent migration to other wireless (or 
wireline) communication methods. 

Background of the Product Concept 

The availability of Palmtop computers, along with compat- 
ible paging devices and services, created the potential for 
wireless transmission of patient data to these tiny computers. 
The early product concept included the original Palmtop 
(the HP 95LX). and a paging device called the NewsStream, 
which connected to the serial port of the Palmtop using a 
cradle. The HP 95LX display allowed only coarse wav eform 
presentation, and the combination of the Palmtop, cradle, 
and NewsStream was somewhat unwieldy. However, proto- 
typing based on these concepts, using the 12-lead ECG, 
showed the feasibility of the product idea. 

Dr. David Albert, a technology oriented physician with pre- 
vious ties to die HP Diagnostic Cardiology Division, became 
a champion for commercialization of the product. Having 
formed a company (Data Critical Corporation, or DCC) lo 
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Data Through Paging Technology 



The Dala Through Paging software, which is licensed to HP by Data 
Critical Corporation, allows patient information in the form of a binary 
file (the clinical message file) to be transmitted through a conventional 
alphanumeric paging system and received on a palmtop computer 
equipped with a NewsCard paging receiver 

Transmission Data Structure 

Two types of pages are generated and transmitted by the dispatch station 
application. The first type is the file identification packet. This page is 
sent redundantly as the first and last packets. It identifies the clinical 
message file and provides the clinical callback phone number and the 
name of the institution This page is sent as readable text and is dis- 
played when the clinical message is not received successfully 

The second type of page is Ihe clinical message packet The clinical 
message file is divided into clinical message packets using the process- 
ing step outlined below. The clinical message packets can be transmitted 
redundantly if that feature is selected in the dispatch station application. 

Clinical Message File Compression 

The clinical message file is compressed using a lossless compression 
algorithm The approach, which is based on industry-standard concepts 
and algorithms, is referred to as LVSS The algorithm employs dictionary- 
based and Huffman encoding processes This combined algorithm is 
similar to the commercially available LHARC program and the widely 
used PKZIP The compression is intended to decrease the number of 
pages sent through the paging service provider by about 50%. As part of 
the compression process, a 16-bit CRC error detection code is computed 
and included with the compressed clinical message lile. The CRC serves 
both to check the integrity of the compression process and to detect 
errors that might have been introduced by the transmission process. 

Encoding 

The compressed clinical message file, which is in the form of 8-bit binary 
data, is translated into 7-bit printable ASCII characters. The binary-to- 
ASCII encoding step is necessary to use the paging system, which was 
originally intended for the transmission of only printable ASCII charac- 
ters The algorithm is similar to the uuencode utility used with many 
UNIX* email programs. This process tends to introduce an overhead of 
30% in the clinical message file size This encoding overhead is more 
than offset by the gains obtained through compression. 

Packetization 

The encoded clinical message file is divided into small blocks of ASCII 
characters. The size of a block is dictated by the maximum page length 
allowed by the specific paging service used Each block contains header 



pursue building products based on this technology, he 
searched for partners to provide access to sources of clini- 
cal patient information as well as established marketing 
Channels. He found an enthusiastic sponsor in Jim C'yrier. 
the division manager of HP's patient monitoring business. 
Jim had a well-developed vision of the future needs of medi- 
cal professionals for access to patient data whenever and 
wherever they were, so he saw great promise in this product 
concept. Jim set in motion a process that resulted in a con- 
tract between HP and Dr. Albert's company for the joint 
development and marketing of the PalmVue system. 



information for later identification of the data block, which allows correct 
reconstruction of the clinical message file after reception in the palmtop 
The header contains a clinical message file filename, a block sequence 
number, the total number of blocks in the clinical message file, and error 
detection codes. Each block is then packaged into a page with Telocator 
Access Protocol (TAP) control characters embedded in preparation for 
sending to the paging service by modem. Each page also contains infor- 
mation that is used later in the RF transmission stage to target specific 
receiving pagers. 

Data Transmission 

A telephone line connection is established between the dispatch station 
modem and the central paging switch modem. TAP is used to upload the 
packetized clinical message file to the paging switch TAP establishes 
communication handshaking, performs forward-acting error correction 
using checksum calculation, and retransmits erroneous packets when 
requested The uploaded pages are then RF-transmitted to the target 
pager device (or devices) by the central paging system. The order of trans- 
mission of the packets is not necessarily the same as the order of recep- 
tion by the paging switch 

Receiving Pages 

On the receiving end of the RF link, the process is reversed to recreate 
the original clinical message file All pages in a clinical message file are 
stored by the NewsCard paging receiver in its local memory, where they 
can be downloaded into the receiving palmtop computer The relevant 
clinical message file pages are then redirected to a temporary incoming 
clinical message file page file based on the header information supplied 
with each page. The last page sent contains a coded message that acti- 
vates a palmtop macro to start processing 

Clinical Message File Reconstruction 

The HP PalmVue application accesses the incoming clinical message 
file page file and. using the page header information, reorders and 
reassembles the received pages. The reassembled page message is then 
translated from 7-bit ASCII to 8-bit binary data to reverse the pretrans- 
mission encoding process The decoded clinical message file page file is 
then decompressed to reconstruct the original clinical message file, which 
is then stored. It is displayed by the palmtop application only if the CRC 
sent with the clinical message file matches the CRC computed by the 
palmtop. 

UNIX is a registered trademark in [he United States and other countries, licensed exclusively 
through X/Open Company limited 

X/Open is a registered trademark and the X device is a trademark ot X/Open Company limited 
in the UK and other countries. 



Underlying this product are two major concepts. One is the 
usefulness of providing complex patient dala to physicians 
on a pocket-sized device, whic h is enabled by the advent of 
the IIP palmtop, a tiny computer with a high-resolution 
graphics display. The other is the ability (seen by many in 
the paging industry as "not possible") to send large, binary 
information files through the standard and ubiquitous alpha- 
numeric paging systems. Refer to "Data Through Paging 
Technology" above for the details of the data compression, 
translation, packet izing and reconstruction process used to 
implement this capability. 
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Product Development 

The product definition for HP PaJniVue was a joint effort of 
the engineering teams from the HP Patient Monitoring and 
Diagnostic Cardiology Divisions, working together with Data 
Critical Corporation. The primary design goals were to pro- 
vide high quality and useful displays of patient data on the 
palmtop computer, to provide a very simple and intuitive user 
interface for the palmtop user, and to ensure the integrity of 
any patient data presented to the physician. The patient moni- 
toring team developed a prototype of the palmtop displays, 
using Visual BASIC on a PC". These display screens were 
transferred to the palmtop, where they provided detailed 
screen formats and basic user interface controls. This proved 
to be a very effective method for quickly developing detailed 
prototype screen formats and control structures for evalua- 
tion by the development team and representative clinical 
users. 

The development of the HP PalmVue critical care and ECO- 
stat applications followed separate paths. The critical care 
product built on existing software products to provide a 
framework for the dispatch station application and a proven 
subsystem to acquire patient data from the HP CareNet 
patient monitoring network. The PC application to provide 
the HP PalmVue user interface was developed by the engi- 
neering team in the HP European Project Engineering Center 
by leveraging their DocVue product. Data Critical Corpora- 
lion, under the development provisions of the contract, de- 
veloped the transmission software for the dispatch station 
PC and the data reconstruction and user application soft- 
ware for the palmtop. The program management, system 
integration, testing, and product documentation were per- 
formed by the project team at the HP Patient Monitoring 
Division. 

The development path for the IIP PalmVue ECGslat product 
was far simpler. The HP Diagnostic Cardiology Division de- 
veloped the initial product specification and Data Critical 
( 'orporation developed all of the PC and palmtop software. 
Substantial portions of the software (other than the PC user 
application) arc common between the I wo products. 

The joint development plan for these products made optimal 
use of the strengths of the partners. The III* patient monitor- 
ing and cardiology groups have substantial knowledge of 
their respective clinical application areas. They also have 
highly refined and formalized processes for product defini- 
tion, architectural design, regulatory approval, and software 
Quality assurance In the case Of the critical care prodmi. 
existing product software from the III' European Project 



Engineering Center was also a key HP contribution. Data 
Critical Corporation provided their established Data Through 
Paging technology, current knowledge of paging systems and 
paging devices, and specific expertise in programming in the 
system manager environment of the HP 200LX palmtop. 
Substantial learning occurred by all of the partners. Data 
Critical Corporation was forced to conform to the rigorous 
testing and software QA methods required by HP's regulatory 
and ISO 9001 processes, while HP embraced the spirit of 
rapid product creation and aggressive attitudes that are the 
strengths of a small startup company. 

The project teams needed to adapt quickly to evolving tech- 
nology as the project progressed. While the early prototype 
was based on the HP 95LX, the HP 100LX was introduced 
during the early stages of the development work. By the 
time of product release, the HP 200LX was announced and 
became the platform for the initial HP PalmVue products. 
The paging device evolved from the bulky NewsStream to 
the PCMCIA-based NewsCard. The advent of the NewsCard 
provides the end user with a compact receiver setup that 
can be readily carried in a pocket or purse. A team in HP 
Corvallis and HP Singapore was concurrently developing 
interface software for the NewsCard. and they modified 
I heir software product to make HP PalmVue possible. 
Adapting to these changes required the development and 
test teams to be flexible and efficiently rework their soft- 
ware and test procedures to accommodate the evolving HP 
PalmVue product configuration. 
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Constructing An Application Server 



In a dynamic networked environment in which there are several hundred 
workstations and servers there is a constant demand for new versions of 
software. In this environment software installation procedures must be 
quick, flexible, and tolerant of change. 

by Jill E. Swenson 



With the rapid advancements and constant changes associ- 
ated with computer technology, new and hetter hardware 
and software capabilities can always he expected. Hardware 
comes and goes as needs fluctuate, and software popularity 
tends to bloom and fade as fast as software features evolve. 
All this change makes managing software installation and 
updates across more than 000 UNIX * systems a very chal- 
lenging task. This paper describes a project to simplify soft- 
ware administration among a group of workstations at Ill's 
Integrated Circuits Business Division. 

At one time our division software was purchased by system 
owners and installed on individual workstations as requested. 
Users shared common applications by connecting their work- 
stations in HP-UX* clusters in which one machine's disks 
were used by many diskless workstations (modes).' These 
clusters grew large, and access to soft ware became a more 
important component in deciding system configuration than 
performance or networking issues. Some software was 
shared between cluster servers through NFS mounts, and 
this led to what we call "spaghetti mounts," which is many 
machines mounting portions of each others' disks to access 
shared software (Yig. 1). Additionally, software installations 



were not tracked, software versions were not synchronized, 
and network licensing was not effectively implemented. 

My goal for this project was to find a way to reduce users' 
dependencies on cluster configurations, to untangle the 
mounts, and to improve the way we installed, updated, 
removed, and tracked software. To do this, I moved the 
application code files to a central server and connected all 
the user workstations to this server (see Fig. 2). File servers 
are not an unusual concept, but application servers create 
unique challenges, and this one needed to be as easy to use 
as possible. 

Developing the Structure 

Since we had some spare equipment and disk space, a central 
software server was a convenient choice for the application 
server. The basic concept was in place — add disks to the 
application server, install software on those disks, mount 
those disks to client machines, and enable the client ma- 
chines to run the software. Two issues that had to be dealt 
with were how to mount disks so that symbolic links would 
be followed correctly on the application server and on the 
clients, and how to isolate each application and allow it to 
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reside in its desired location on each system. Finally, since 
saving administrative effort was equally important, the 
entire process needed to be automated 

A search of the literature produced a helpful article describ- 
ing how lo manage local software on a network. 2 Even more 
conveniently, the article included Hie author's installation 
script. Although not entirely suitable for our environment, 
this article provided valuable ideas for establishing mount 
points, isolating applications, and creating configuration 
files for each application. 

Mount Points 

To identify mount points. I looked at documentation for the 
HP-internal I 'NIX Common Operating Environment (UX- 
COE) and the HP-l'X 10.0 operating system. Both docu- 
ments recommended using different locations for mounting 
local and remote (NFS-mounted) disks. This meant that disks 
physically connected to the application server would be 
mounted in one location on the server (e.g., /mnt/diskl) and in 
a different location on the server's clients (e.g.. /nfs/servername/ 
diskl ) (see Fig. 3). This approach makes logical sense, but ii 
is limited because there is a route to a file on the server that 
the client doesn't know about. In other words, the server 
could refer In a file h> the name 'mnt/diskl/filename, bin that 
name would not he valid on a client. The client must call 
that file /nls/servername/diskl/filename. 
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Fig. 2. A network configuration 
in which many machines are 
mounted to an application server 
to gain access to shared software. 



Fig. 3. An example uf using different local inns in mount local 
and remote disks. 



Why Is this a problem? 

Calling a file by multiple names typically does not cause 
problems. However, most application installation programs 
have a problem with multiple names because they act under 
the assumption that code is installed on the machine where 
it will be used and not on an application server. -Many instal- 
lation programs detect the directory into which code is 
installed and then plug that directory name into scripts, use 
it to create symbolic links, and so on. The resulting scripts 
and links work correctly on the application server, but fail 
on client systems. 

To handle this, disks were mounted in the recommended 
locations and symbolic links were created on the application 
server to allow it to refer to its own disks under the names 
used by the clients. Thus, when Software is installed it is 
always redirect etl, if possible, lo the name used by clients. 

In retrospect, this was not the best solution. Some particu- 
larly difficult installation processes resolve all symbolic 
links to their absolute paths and use these paths lo create 
scripts and symbolic links. Thus, no matter what name was 
used for the installation directory, I would find some refer- 
ence to /mnt/diskl I ucked away in a software configuration 
file or script. The only way to fool these programs is to 
either ignore recommended standards and mount the disks 
to /nfs/servername/diskl on both the client and the server, or 
create "fake" symbolic links to the mount points on both 
machines. 

After considering both options. I determined that the first 
option had the least number of disadvantages and was the 
simplest to implement. 

Software Organization 

The next <|uoslion was how lo organize the software on the 
shared disks, t 'pinions varied, t >nc approach was to pin all 
code into a common bin directory and set it up so that the 
administrator owned the bin directory on all machines. 
Although this would ensure consistency, it wasn't very 
flexible. Since all users don't have identical software needs 
(some may be testing a new version of software while 
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Qtliers might be installing software packages that are not 
shared with others), il did not make sense to force all sys- 
lems lo have an identical bin directory. 

The approach used in reference 2 suggested isolating each 
application in its own directory tree and organizing the com- 
ponents of the application in explicit directories (documen- 
tation files under the doc subdirectory, binaries under bin, 
etc.). This idea of isolation was good, hut il required spend- 
ing l ime unnecessarily reorganizing the code components. 

The software packages we were dealing with came from 
multiple developers, each of whom had a different idea ahout 
where an application's files should reside and the relative 
location of different components such as library, binary, and 
configuration files. There was some concern t hat many of 
these software packages would not react well to being moved 
around or being forced to rim out of an unexpected directory. 
The best approach was to install each application into a 
separate directory on the shared disks, and to use symbolic 
links to allow the application's files (o be logically located 
wherever they would normally expect lo be installed. 

To keep this neat, each software package is installed into its 
own directory as if I hat directory were the root directory on 
the system, hi other words, if an application called editor 
came with a file called editor.dict, which it expected to reside 
in /usr/local/lib, a directory for the new application would be 
created: 

/nfs /servernaine /diskl/ editor 

and the editor.dict(ionary) file would be installed in 

/nf B/servername /diskl /edit or /usr/local/lib 
/editor . diet 

When this software is finally hooked up to client systems, 
they will each have a symbolic link: 

/usr/local/lib/editor .diet -> 

/nf s/servername/di ski /editor /usr/local/lib 

/editor.dict 

The software can find its data file where it expects, and all 
the files associated with the editor program can be isolated in 
one directory tree which can be easily removed, replaced, or 
modified as needed. 

Each application's directory tree mimics the root file system, 
making it easy to see where the software components will 
ultimately reside on client systems. Developers like the de- 
sign because they can easily see the relative relationship of 
all their files in isolation. 

There are two significant issues with this approach. First, it 
requires thai a large number of symbolic links be maintained 
On nudtiple systems. Second, some applications might require 
configuration changes on the client or insist that certain 
files physically reside on the client's hard disk. 

The solution to both of these problems is a configuration file 
and a process (script ) to use il. 

Configuration File 

Every application on the application server has an associated 
configuration file. This is an ASCII file, created manually, 
that contains all the instructions necessary for installing the 



application on a client. For most applications, the configura- 
tion file simply lists a number of symbolic links to create, hi 
the example above, one line in the editor program's configu- 
ration file would look like: 

LINK : /nfs/ servernaine /diskl /editor /usr/local/lib 
/editor .diet : /usr/local/lib/editor .diet 

Each line in the configuration file contains a tag field fol- 
lowed by several colon-separated parameters. The lay field 
is a word that has meaning lo the configuration script. In 
this example, the LINK tag tells the script to create a sym- 
bolic link using the next two fields as arguments. The syntax 
for the LINK command is: 

LINK: /link/to/directory: / 1 ink/ from/directory 

Additional tags cause the configuration script to copy files 
( COPY), unlink directories (UNLINK), or execute programs. 

Creating a configuration file is the most time-consuming 
action required when installing an application. It requires a 
good knowledge of the directory structure on client machines 
and an understanding of the run-time environment expected 
by the application. The overall goal is lo minimize the number 
of links while allowing nudtiple applications to be installed 
where they wish. However, with a little creativity, nearly any 
application can be dealt with, and once the configuration file 
is constructed, il remains unchanged and can be used on 
every client. 

The configuration file is also used to un install software. An 
option on the configuration script causes il lo deal with cer- 
tain commands in reverse, removing links and files that had 
been copied to the client. 

In accordance with HP-UX 10:0 file structure recommenda- 
tions, the configuration file is created in /etc/opt/appname/con- 
fig.fs. To make the configuration files readable from client 
machines, they are placed under each application's directory 
tree. Thus, the /nfs/servername/diskl/editor/etc/opt/editor/config.fs 
file would be the configuration file for the editor application 
mentioned above. 

The Script 

The configuration script is used to install an application 
located on a file server on a workstation (i.e., it sets up links 
to applications on the server). Because the configuration 
(and application) files reside on a remote server, a new client 
must mount the remote server's disks before installing soft- 
ware. The installation script establishes mounts (-m option) 
to the file server and creates the required links (-c option) 
using information from the configuration file. The installa- 
tion script has an option ( u) to undo a mount and uninstall 
software. The command line to the configuration script to 
establish the mount points and set up the links for the editor 
application would be: 

scriptname -m servername : /mnt /diskl : /nfs/ 
servername/diskl -f -c /nf s/servername/ 
diskl /editor /etc /opt /edi tor /conf ig. f s 

The -m option Introduces the server and client involved in 
establishing the mount points, and the -f and-c options intro- 
duce the configuration file. 
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The configuration script is written in Perl (Practical Extrac- 
tion Report Language ) because this is the language that pro- 
vides the easiest and most efficient techniques for reading 
through the configuration file once, storing the information, 
and acting on il later. Shell scripts require more coding to 
perform the sanie steps, and a C program would have ro be 
compiled for every platform we support. Thus. Perl was a 
good choice. Fig. 4 shows the portions of the installation 
script responsible for mounting disks and reading a configu- 
ration file. 

The configuration script reads and acts on instructions in 
the configuration file. It checks the first field of each line for 
a tag. which is a special word (e.g.. LINK) describing a com- 
mand. Unknown tags are ignored. 

Because the configuration files reside on the server, clients 
must mount 'he server's disk before attempting to read any 
configuration files. Although the configuration script can be 
used to mount the servers disk, it does not currently modify 
a client's boot procedures or its /etc/checklist file. The system 
administrator still needs to perform these steps manually. 

The configuration script uses the same configuration file for 
installing and iininstalling. It does an uninstall by removing 
all files or directories listed as LINK or COPY in the configura- 
tion file. 

Remaining Issues 

With any project there are always lingering issues. This sec- 
lion describes some of I hese issues. 

Software Location and Fine-Tuning. Although it's convenient to 
locate software centrally, not everything belongs on a remote 
machine. Ideally, enough software should remain on local 
workstations so that the users are reasonably functional 
when the application Server is down for maintenance. This 
means that key files such as operating system components, 
screen icons, and critical applications such as electronic- 
mail readers should reside on local systems. Also, perfor- 
mance is impacted by accessing remote files so finding the 
right mix of local and remote files can have a significant role 
in application performance. 

Software Installation Programs and Headaches. Most installation 
programs expect the code to be installed on the machine 
from which it Ls run and don't embrace the concept of remote 
access. Good installation programs allow you to change the 
default installation location and log every step they take, 
and the friendliest programs place all files under a user- 
specified location. Bad installation programs silently tread 
in certain system areas by adding user accounts, modifying 
boot scripts, and changing the system configuration. Bypass- 
ing installation programs, tracking down all the changes 
they made, and rewriting processes to duplicate the installa- 
tion on client machines is the most time-consuming part of 
installing new soft ware. 



Read-only Environment. Ideally, the application server's disks 
should be mounted read-only. Unfortunately, some applica- 
tions require write access to shared files, so we use read- 
write NFS mounts. However, application directory permis- 
sions are kept tight so that users are not able t< i write to the 
server. 

File Ownership Conflicts. I iccasionally, two different applica- 
tion programs will both try to "own" the same file. 1 first 
encountered this with two Lotus 1 ' applications I was install- 
ing: AmiProA 'X and Lotus Notes/l*X. Both versions came 
with an /optflotus/nin/lpconfig file and the files were not identical. 
Normally, the version a client receives depends on the order 
in which the two software packages are installed. If AmiPro 
Ls installed last, a client will run AmiPro's version of the 
Ipconfig file. If Lotus Notes is installed last, the client will run 
the Notes version. 

Inconsistency and Supportability. To ensure that all users, no 
matter which software package was installed, used the same 
application versions, some rearranging was necessary. I in- 
stalled the Lotus applications mentioned above on the appli- 
cation server into their own separate directories. Next. I 
copied all duplicate files to a third directory, using the ver- 
sion of the files that came with AmiPro. Finally. I modified 
the configuration files for both AmiPro and Lotus Notes so 
that clients would link to these duplicate files in the common 
directory. 

This fix allowed the complete AmiPro and Lotus Notes prod- 
ucts to be installed and available, ir a problem arises with 
any of the common files, it's easy to change the file in one 
place and make sure the fix reaches everyone. 

Summary 

Overall, the application installation process has been a great 
success. Users are running consistent versions of applica- 
tions, sharing centrally managed licenses, and no longer 
choosing to be part of a cluster simply because of the soft- 
ware available on that cluster. Application providers are 
able to make modifications in one location accessed by 
everyone. The application server contains no user accounts, 
runs very few processes, and is a fairly well-behaved I/O- 
dedicated machine. Unlike a cluster, the server can suffer 
occasional downtime without bringing down client systems. 

We still run clusters, and the application server works in 
that environment as well. But the clusters are smaller and 
they are being implemented for the right reasons — not 
because of application availability. Many users are choosing 
standalone workstations, where they are allowed greater 
flexibility to install experimental versions of code or to use 
as much swap and disk space as they like without impacting 
other users. 
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ft Options: 

# -m Mountinfo: Revive/establish mount points 
-c Configfile: Revive/establish links 
-f: Force symlinks and mounts (removes 

existing files and directories). 
-u:Unmount or remove links, depending 

on other options used 
-v: Verbose 



V 
# 
# 
# 
# 

# 

require 'getopts.pl'; 

do Getoptsl 'm:c:fuv' ) ; A; 

# Initialize variables 

$numlinks=0; 

Snumunlinks=0; 



tt Read mount information. # 
#########tt»###t»#####tt#################tt######### 
sub readmount { 

print "Starting readmount subroutine \n" 

if (Sopt^v); 

# The mount parameter consists of the machine 

# to mount from, the directory on that machine 

# to mount and the directory to mount to (on 
tt the client machine), all separated by ":" 

# characters. 

tt Break line into its components. 
B © (5) 

($machine, $mountfrom, Smountto) =split 
(1:1, $mountpoint ) ; 



)else 
( 

exit 97; 

} 

) # End subroutine makemountB 

S Read config file, filling up variables with # 
tt contents. tt 
###########################((#(( (t####tt######tt####tt 

sub readconfig { 

print "Starting readconfig subroutine \n" 
if ($opt_v); 

while ($_=<CONFIGFILE>){ (g) 

tt The configuration file consists of an initial 

# tag and colon-separated parameters. Break each 

# line into its components 

chop; 

(Stag, Uparms) =split ( / : / ) 



if (Stag eq "LINK" ) (ff) 

Slinkto [Snumlinks] =Sparms [0] ; I 
Slinkfrom[$numlinks] =Sparms [1] ; (J) 
$numlinks++ ; 
) 



)# while 

} # End of subroutine readconfig 



) tt End subroutine readmount 

##########################################*##### 

# Perform mounts, creating directories, if tt 

# needed. # 
##ff###################tt###########tt#####tttt###tttttt 
sub makemounts { 

$dontdo=0 

if ( substrf Smountto, 0, l)eq '/') 
{ 

print "Making" -Smountto ."\n"; 
if ( ( system) "/usr/bin/bdf Smountto I /bin/ 
grep Smachine : Smountf rom" ) ) ==0 ) 
{ 

print "Correct mount point already exists\n" 
$dontdo=l; 

&makedir ("Smountto"); (jp 

print "mounting Smachine : Smountf rom\n" ; 

if (<-d Smountto ) &s ( !Sdontdo) ) 

{ 

system ("/etc /mount -o soft Smachine: 

Smountf rom Smountto"); 

) 



######tt#####tt###tt########tttt#tt#################tt# 

# Process links: Create all links specified in # 
tt config file (must run readconfig!) first). # 
tt###tt#tt##tt##tt#######tt###tt#####################tt# 
sub linkall { 

print "Starting linkall subroutine \n" 
if ($opt v) ,- 

for ($i=0; $i< ( Snumlinks ) ; Si*+) 

{ 

Slinkf rompath=Slinkf rom[Sil ; 
Slinkf rompath= s' [a-z 0-9.\-]*S"; 
# Chop file/dir name off path 

# If parent directory path doesn't exist, 

# create it. 

&makedir ( "Slinkf rompath" ) ; 

# Check for existing file/link (exit or 

# remove it depending on -f option) 
if (-e Slinkf rom [Si] &S( ! Sopt_f ) ) 

{ 

print "Non-Link exists:" . Slinkf rom[ Si] • 
"Terminating \n"; 



Fig. 4. Portions of the configuration script for mounting disks, reading configuration files, and creating links. 
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exit 98: 

> 



elsif (-e SlinkfromtSi] >SS(Sopt_f > > 

{ 

I Force (-£) section — force the link (remove 
* existing file or directory tree, 
if <-f Slinkfrom(Si] t 
< 

print "Forcing removal of File" 
-SlinkfromtSi] . "\n"; 
unlink (Slinkf rom[Si] ; 
> 

elsif <-d SlinkfromtSi] ) 
{ 

print "Forcing removal of directory" 
. Slinkf rom[$i] . "\n"; 

system ("/bin/rm -rf SlinkfromtSi]"); 

) 



> 

for ($i=0; $i< ( Snumlinks ) ; $i++) 

{ 

symlink ( Slinkto [Si] , Slinkf romtSi] ; K 
print "Linking from " . Slinkf rom [ Si ] . 
"to " .$linkto[Si] . "\n"; 
) 



Fig. 4. (Continued) 
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Input Siring 

-m servername: /mnt/diskl : /nfs/ servername/ 
disks -f -c /nf B/servername/disks/editor/ 
etc/opt /editor /config. f s 

Server s Name 

Servers Name (or Diskl met /disk 

Client's Mount Point nfs /servername /diskl 

Make Directory /nf s/ servername /diskl 

Mount nf s/servername/diskl to mnt/diskl 

config. sys 

Tag = LINK 

/nf s/ servername /diskl /editor /usr/ local/ 
lib/editor. diet 

/usr /local /lib/ edit or .diet 

Create Symbolic Link: 

/usr/local/lib/editor . diet -> nfs/ 
server name /diskl /editor /usr /local /lib/ 
editor .diet 
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Interface Translation for Reuse of 
Assembly-Language Modules in a 
TWo-Language Environment 

A mixture of low-level and high-level implementation languages is likely 
when old modules are reused. In a two-language system, some interfaces 
must be expressed in both languages. This paper describes the design and 
implementation of a production-quality software tool that solves this 
problem for the C programming language. 

by James R. Buffenbarger 



Tlie advantages of developing a software system in a high- 
level programming language rattier titan a low-level assembly 
language are well-known. Nevertheless, many embedded 
systems have been and continue to be developed in a low- 
level language. This implementation language paradox is typi- 
cally justified in terms of the required execution efficiency 
or the lack of high-level software development tools. 

Typically, a new system is built from a mixture of old and 
new modules. The old modules are often from a previous 
system. Depending on their age, (hey may be implemented 
in a low-level language. The new modules might be imple- 
mented in a low-level or high-level language. 

This paper is concerned with the development and reuse of 
intermodule interfaces in a system requiring a mixture of 
low-level and high-level implementation languages. Such a 
mixture is likely when old modules are reused. New modules 
might also be implemented in a low-level language, but they 
are more likely to be implemented in a high-level language, 
since processors are getting faster, memories are getting 
larger, and high-level software-development tools are 
becoming available. 

In this paper, a problem is identified and defined, several 
possible approaches are proposed, and the most promising 
approach is selected and pursued. The design and imple- 
mentation of a production-quality software tool that solves 
the problem for the C programming language are described 
in detail and short-term industrial experiences with this tool 
are briefly described. 

The Problem and Possible Solutions 

Suppose a two-language system contains a module named f. 
Clearly, t should have only one implementation. However, 
f may need two equivalent interfaces: one for each language. 
There ar e sev eral possible approaches: 
• Manually develop and maintain a low-level interface only. 
This approach requires f and every user of its interface to be 
implemented in the low-level language. However, t or one of 
its users may be a new module, which suggests a high-level 
implementation. 



• Manually develop and maintain a high-level interface only. 
This approach requires f and every user of its interface to be 
implemented in the high-level language. However, for one 
of its users may be an old low-level module, which should 
be reused rather than reimplemenled. 

• Manually develop and niainiain both interfaces. This 
approach allows f to be implemented in either language. 
However, the probability of inconsistency is very high, as 
it is for any instance of double maintenance. 

I tevelop and maintain the high-level interface manually and 
derive the low-level interface automatically, according to a 
well-defined transformation. This approach also allows f to 
be implemented in either language, but avoids double main- 
tenance. Note that the reverse transformation is not possible. 

Interface Translation 

The last of these approaches seems to be the most reason- 
able, and is pursued here. Interface translation is flexible, 
accurate, and fast. 

In many languages, an interface is contained in what is 
called an include file. Thus, deriving a low-level interface 
from a high-level interface means translating an include file 
written in a high-level language into an include file written 
in a low-level language. An include-file translator can be 
used in at least two ways. 

Suppose a programmer is writing a module named g and 
needs to use a module named f. If the programmer is an 
assembly-language programmer, module f needs to consist 
of an assembly-language include file f.inc. which specifies the 
interlace of f, and a binary object file f.obj for linking. On the 
other hand, if I he g programmer is a C'-language programmer, 
module t needs to consist of a C include file f.h. which speci- 
fies the interface oft. and a binary object file f.obj for linking. 
Therefore, the "user view" of module f is the three files: f ine, 
f.h. and f.obj. These three files must be available so that both 
assembly-language and ( '-language programmers can use 
module f. 
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Fig. 1 . For a module I, written in assembly language, to be usable 
by boih assembly-language and I* programmers, the four files 
shown here are needed With an inrlude-file translator, only the 
files on the left need to be maintained manually. 

Module f ntay be vsTitten either in assembly language or in C. 
If ii is written in assembly-language, there will be an assem- 
bly-language file f.a96 which Implements the interface off 
and includes f ine. If f is written in C. there will be a C file f.c 
which implements the interface of f and includes f.h. 

Therefore, if f is written in assembly language, the following 
files are necessary so that both assembly-language and C 
programmers can use module f: f.h. f.a96. fine, and f.obj. With 
an include-file translator, only f.h and f a96 need to be main- 
tained manually; fine can be translated from f.h. and f.obj is 
assembled from f.a96. The processes are shown in Fig. 1. 

If f is written in C, the following files are necessary: f.h. fx, 
fine, and f.obj. Again, with an include-file translator, only f.h 
and f.c need to be maintained manually: f ine can be trans- 
lated from f.h, and f.obj is compiled from f.c. The processes 
are illustrated in Fig. 2. 

Include-file translation is similar to compilation. In fact, one 
way of interpreting these ideas is as additional requirements 
for a compiler. Perhaps compiler/assembler vendors will 
evenlually incorporate these features into their products. 

The ideas presented here are programming language inde- 
pendenl. However, for demonstration purposes, a particular 
assembly language and a particular high-level language (<") 
are discussed. Furthermore, just one implementation of 
what should be considered a class of translation tools is 
described. 

Pretranslator Environment 

We begin with a description of mi environment that needs an 
include-file t ranslator. 

The software is developed in an evolutionary way, in a heter- 
ogeneous environment, The software is large and mature, 
residing in an centralized version-controlled repository. 
The development platforms are workstations based on the 
I NIX 1 . MS- 1>< IS 1 . and I >S2 operating systems The i.m/ri 
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Fin. 2. Poi a module i. written in C, to be usable by both assembly- 
langiuiHr- Wtd CpBOjBunrners. the four fil<'s shown hen- >ir>- needed 
With art iii< hide-file translator, only the files on the left need to be 
maiiiliiiiii'd m.muall.v. 



plnlfnnn is an embedded system based on an Intel micro- 
controller. The software is developed in assembly language 
because good cross-compilers for the target platform do not 
exist, compiler-generated code is too slow, and compiler- 
generated code is too big. 

Eventually, the software developers and their managers are 
ready for a change. New microcontrollers are much faster, 
and they can address much more memory. Management 
recognizes the [>otential benefits of assembler and processor 
independence, not the least of wliich is the freedom to buy 
development tools (e.g.. emulators) from more than one 
vendor. Good cross-compilers are finally available. New 
developers would become productive more quickly if they 
did not have to learn an esoteric assembly language. All 
developers would become more productive if they could 
program in a high-level language when appropriate. 

fat this environment, the high-level language of choice is C. 
but its complete and immediate adoption has well-founded 
resistance. For speed and space efficiency, some parts of the 
software should never be rewritten in C. Furthermore, those 
parts Of the software that should be rewritten in C represent 
an enormous corporate investment. An effort to rewrite all 
of them at once would have severe short-term productivity 
and quality costs. Instead, the unanimous understanding is 
that only some of the assembly-language modules should be 
replaced by C modules, and then only in a prioritized piece- 
meal fashion. Thus, the environment must support two- 
language development. 

A Tool for Two-Language Development 

Consider the consequences of rewriting an assembly- 
language module named f in C. The original module has two 
parts: an assembly-language file named f ine, specifying the 
module's interface, and an assembly-language file named 
f.a96. implementing the module's interface. 

Likewise, the new module has two parts: aC file named f.h, 
specifying the module's interlace, and a (' file named f.c. 
implementing the module's interface 

However, other assembly language modules still need the 
assembly-language interface to f. That is. they need to in- 
clude fine in one way or another. One solution is to maintain 
both f.h and fine manually. This solution is tedious and error- 
prone. A better solution is to maintain f.h manually and auto- 
matically translate it into f ine with a tool. Such a tool needs 
to be able to translate the subset ol'C thai occurs in a h file 
into assembly language. 

Two brief definitions are relevant. A target assembler is a 
cross-assembler from a development platform to the target 
platform Analogously, a target rompilcris a C cross-compiler 
from a development platform to the target platform. Note 
that the word size of the compiler with which the translator 
is developed typically differs from that of a target assemble!'/ 
compiler pair. 

The characteristics of (' are fairly standardized, stable, anil 
well-known; those of assembly language are not Thus, the 
translator needs to be retargetable, primarily for different 
target assembler/compiler pairs. Several aspects of a partic- 
ular target assembler/compiler pair are described below, not 
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because they are interesting in themselves, bul because Ihey 
provide insight into the translation task anil help explain the 
example presented later. 

The target assembler has several relevant characteristics. 
Ii uses a preprocessor, similar to a (' preprocessor, to effect 
file inclusion, macro definition, and conditional inclusion. 
Ii processes two kinds of equate directive. EQU and SET, whose 
difference is irrelevant here. It processes EXTRN directives, 
which are analogous to C extern declarations. Symbols and 
values have types such as: NULL, BYTE. WORD. POINTER, and 
ENTRY. During assembly, the output for each statement goes 
to one of several segments that are available (e.g., code, 
data, stack, or register). 

The target compiler has only one relevant characteristic. 
Its algorithm for determining the distance from the begin- 
ning of a struct to a member requires alignment analysis of 
the types of all members of the struct 

Include-File Translation versus Compilation 

Although the translator is much like a C-subset compiler, 
there are significant differences. For example, the translator 
generates code from a #define directive, but a compiler does 
not. On the other hand, a compiler generates code from 
statements included by a /include directive, hut the translator 
does not. 

A more interesting difference concerns error handling. 
A compiler can stop producing output (i.e., object code) as 
soon as it detects any nonwarning error. In contrast, the 
translator must recover from most errors. Including syntax 
errors, and produce as much col lect output (i.e., assembly 
code) as it can. In many cases, translation errors are quite 
acceptable, representing C declarations that are simply 
inaccessible to assembly-language programmers. 

Translation Details 

The includc-file translator accepts as input a subset of the C 
programming language. This subset consists of 0 modules 
(also known as translation units' ) that do not define func- 
t ions or variables. Such modules are conventionally stored 
in include files, with a h file name extension. Accordingly, 
the translator need not recognize the following reserved 
words: auto do return break else static case for switch continue 
goto while default if. However, the translator does understand 
the reserved words near and far as qualifiers for pointer 
types. 

Like a conventional compiler,- the translator's operation can 
be understood as a sequence of phases (see Fig. 3): 

1. Prior-inclusion preprocessing 

2. Define directive preprocessing 

3. C preprocessing 

4. Scanning and parsing 
•5. Code generation. 

As usual, phases 4 and 5 are interleaved. The phases are 
described below-. 

Prior-Inclusion Preprocessor. An include file can reference an 
identifier declared in another include file, but the former 
does not necessarily include the latter. The prior-inclusion 
preprocessor solves this problem. 



Prior- Indus ion 
Preprocessing 



Oeline Directive 
Preprocessing 



C Preprocessing 



Scanniny and Parsing 



Code Generation 



Fig. 8. Intiude-flle translator operation consists of a series or phases. 

For example, suppose f.c contains the following: 

(♦include "a.h" 
((include "f.h" 

and f.h references an identifier from a.h. To translate f.h, a.h 
must be processed first. However, declarations from a.h 
must not produce output. 

The prior-inclusion preprocessor solves the problem by con- 
structing a file containing include directives, #line directives, 
and the content of the original input file (i.e.. f.h). Later 
phases only produce output for declarations from the origi- 
nal input file. 

The prior-inclusion preprocessor is implemented with Awk.° 

Define Directive Preprocessor. In general, a *defme directive in 
the input produces output. However, C preprocessors delete 
*define directives. The define directive preprocessor solves 
this problem. 

For example, suppose the following line is line five in file f.h. 
((define SIZE 100 /* size of something */ 

The define directive preprocessor translates this into the 
following lines. 

((define SIZE 100 
#line 5 "f.h" 

%%% "SIZE" %%% SIZE %%% 

Since normal C preprocessing lias not yet been performed, 
the original »define directive must be retained. 

The #line directive allows error messages from subsequent 
phases to accurately specify the location of an error. Here, 
subsequent phases must recognize that a line has been 
inserted during preprocessing. 

The three-character token %%% is effectively a new reserved 
word. C preprocessing ignores all but the fourth token on 
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this line, which ii replaces with the definition of SIZE in the 
usual way. Phases after C preprocessing recognize this state- 
ment and produce output from it corresponding to the origi- 
nal ♦define directive. 

Initially, an @ was used rather than %%% but some C prepro- 
cessors complained about it. The probability of a programmer 
accidently using three adjacent modulus operators seems 
low. The identifier is used as the fourth token, rather than its 
definition, to ensure correct operator precedence during 
evaluation in later phases. If the identifier has no definition, 
a 1 is used as the fourth token. The line ends with %%% to 
prevent the parser from skipping too many tokens during 
error recovery. 

The define directive preprocessor is also implemented with 
Awk. 

C Preprocessor. This preprocessor is an ordinary (' prepro- 
cessor ( e.g., cpp). The translator expects the value of an 
environment variable to specify a particular preprocessor. 

Scanner/Parser. This pan of Hie translator is essentially a 
front end for a normal C compiler. Several differences are: 
Only the subset of C described previously needs to be 
recognized. 

The new %%% statements are recognized. 
The definition part of a %%% statement is evaluated- Since it 
can be any C constant integer expression, its evaluation is 
not trivial. Furthermore, evaluation is simulated to occur 
according to the word size of the target compiler, which 
may be different from the word size of the translator, and 
simulated arithmetic overflow is detected and reported. 
The alternative to evaluating the expression (luring transla- 
tion is to translate it into an equivalent assembly-language 
expression. 

Most errors, including syntax errors, do no! preclude code 
generation. 

The scanner/parser is implemented with Yacc. 1 Lex, 5 and 
GPerf.'"' 

Code Generator, Since the translator only translates declara- 
tions, this part is simpler than the back end of a normal < ' 
Compiler. Its primary task is to output assembly-language 
directives and declarations, based on the content of a typi- 
cal symbol table, which is built by the scanner and parser. 

To yimplity retargeting, target compiler type sizes and type 
alignment rules are encoded in a tabular fashion. Likewise, 
target assembler mnemonics and type names are easily 
modifiable. ( 'ode is generated only for declarations from the 
original input file. Declarations from files it includes produce 
no output. 

Translation Algorithm 

The translation from (' to assembly language is predomi- 
nantly syntax -directed. In other words, each syntactic con- 
struct in the ( ' subset is translated to a line of assembly lan- 
guage. However, as in a normal compiler, the symbol table 
provides context. The translated constructs are described in 
the following paragraphs. 

Deline Directives. A 'define directive, without arguments and 
win ise replacement text is a constant integer expression, is 
translated to a SET directive. The value is that of the expres- 
sion, which is evaluated according to the word size of the 



target compiler. Simulated arithmetic overflow is detected 
and reported. For example, 

#define TWO 1*1 

is translated to: 

TWO SET 2 : NULL 

Other kinds of ^define directives are not translated. 

Enumeration Members. An enum declaration declares at least 
one member. Each such member is translated to an EQU 
directive. The value is that which would be assigned to the 
member by the target compiler. For example. 

enumnumbers { 
zero, 
one, 
two, 

ten=5»2, 

eleven, 

twelve 

); 

is translated to: 

zero EQU 0:NULL 

one EQU 1 : NULL 

two EQU 2 : NULL 

ten EQU 10: NULL 

eleven EQO 11: NULL 

twelve EQU 12: NULL 

Structure and Union Members. A struct or union declaration also 
declares at least one member. Again, each such member is 
translated to an EQU directive. The value is the offset, in 
bytes, from the beginning of the nearest enclosing structure 
or union, according to the target compiler. For example, 

struct str { 
double d; 
double *dp; 
int i; 

char c,*cp,b; 
float f; 

); 

is translated to: 

d EQU 0 : NULL 

dp EQU 4 : NULL 

i EQU 8: NULL 

c EQU 10: NULL 

cp EQU 12: NULL 

b EQU 16: NULL 

f EQU 18: NULL 

Notice that alignment occurs. A command line option 
causes structure and union member names to be qualified 
by the newest enclosing structure or union tag (e.g., the 
translation of (he second member would equate the identifier 
STFLdp to four). 

Nested structure and union declarations force an interesting 
decision. A member's offset can be computed as the distance 
from I he beginning of its (1) nearest enclosing stniclure or 
union or (2) outermost Structure or union. Both offsets are 
v aluable to an assembly language programmer. Both offsets 
require name qualification bo differentiate identical member 
names in distinct structures or unions. However, offset 1 
requires a qualification for each level of nesting, which can 
quickly exhaust the .11 -character length limit for ( ' identifiers. 
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Iii addition, offset 1 allows a programmer to compute offset 
2, as necessary. Therefore, offset 1 is considered the best 
choice. 

Structure and Union Tags. In addition to its members, a struct 
or union declaration optionally declares a lag. Such a tag is 
translated to an EQU. The value is the size in bytes of the 
structure or union, according to the target compiler. For 
example, foi the previous structure, the translation is: 



STR 



EQU 



22 : NULL 



Variable Declarations. A variable declaration (i.e.. a variable 
definition prefixed by extern) is translated to an EXTRN direc- 
tive. For example, 

extern int a[10); 
extern int e; 



is translated to: 



EXTRN 
EXTRN 



a: POINTER 
e:WORD 



These directives are output in data segment space. If the (' 
reserved word register is present, they are output in register 
segment space. 

Function Declarations. A function declaration (i.e.. a proto- 
type) is also translated to an EXTRN directive. For example. 

extern int f(int x, int y); 

is translated to: 

EXTRN f : ENTRY 

These directives are output in code segment space. 
An Example 

This section provides a concrete demonstration of the 
include-file translator described in earlier sections. Relevant 
aspects of the translator's interface are presented and an 
example translation is shown. 

The translator recognizes a variety of command-line argu- 
ments and environment variables, but mosi of them are not 
very interesting. The important command-line arguments 
are: 

-i specifies the input file 

-o specifies the output file 

-q simulates prior inclusion of a 'include file 

-a simulates prior inclusion of a ^include <. > file 

The only important environment variable iscppcmd, which 
allows any C preprocessor to be used, rather than the 
default. Thus, the translator can be executed as follows: 

c2as -i cars.h -o cars . inc 

Suppose cars.h contains the following C code: 

#define MAKELEN 9 
#define CARS 3 

typedef enum {black=10 , red, blue) Color; 
typedef char Make [MAKELEN] ; 
typedef double Price; 
typedef struct Car { 

Color color ,- 

Make make ; 

Price price; 

struct Car "oldcars [CARS-1] ; 
} Car; 



extern Car "car; 

extern Car FixCar(Car car); 

Then, after translation, cars.inc would contain the following 
Intel i960 assembly-language code. 



MAKbLbN 


SET 


9 : NULL 


CARS 


SET 


3 : NULL 


black 


EQU 


10 : NULL 


red 


EQU 


11 : NULL 


blue 


EQU 


12 : NULL 


Car_color 


EQU 


0:NULL 


Car_make 


EQU 


2: NULL 


Car_price 


EQU 


12 : NULL 


Car.oldcars 


EQU 


16 : NULL 


Car 


EQU 


20 : NULL 




DSEG 






EXTRN 


car : POINTER 




CSEG 






EXTRN 


FixCar : ENTRY 



Integration with Build Process 

From a build-process perspective, an include-file translator 
is no different than a compiler: it translates a source file 
into an intermediate form. Like a compiler, the translator's 
invocation should be automated by a build process. There 
are several details, which are described below. A build pro- 
cess based on Make 7 is assumed. 

In general, only some of a system's C include files need to be 
translated. These h files need to be identified. Typically, a 
Make variable is used for this purpose. 

A single rule is sufficient to tell Make how to translate any of 
the previously identified h files into a corresponding -inc 
assembly-language file. Some versions of Make can use sialic 
pattern rules for this, while others can use dynamic prereq- 
uisite macros to accomplish the same thing. If these Make 
features are unavailable, multiple rules are required. 

Any additional dependencies of each resulting inc file must 
be specified explicitly, in two ways. First, Make must be I old 
about the dependencies, but this can be done with oidinan 
rules. Second, such a dependency may require a translator 
option specifying prior-inclusion preprocessing, as described 
above. This second kind of dependency cannot be computed 
automatically. Fortunately, an esoteric Make feature called 
computed variable names carl customize translator options 
for different h files. Again, if these Make features are unavail- 
able, multiple rules are required. 

Conclusion 

Include-file translation supports the reuse of modules whose 
interfaces must be expressed in both a high-level language 
and an assembly language. These two-view interfaces allow 
a module to be Implemented in either language and refer- 
enced by other modules implemented in either language. 
The basic approach is to maintain the high-level interface 
manually and automatically derive the low-level interface. 

The C include-file translator described above has recently 
been implemented and incorporated into (he softwar e build 
process used by a group of about 20 firmware engineers at 
Hewlett-Packard's Disk Memory Division. The translator was 
implemented for the 1 MX and MS-DOS operating systems 
by one person working half time for about six months. The 
firmware upon which the translator operates consists of 
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interested m user interface design and implBmsita- 
lion, he 15 named as an inventor in a patent involving 
lev action and has written five papers on the HP 
48G/GX.theHP48S'SX.andtheHP41 Ted was bom 
•n West Lafayette. Indiana and was awarded a BS 
degree In computer and electrical engineering m 
1984 (rom Purdue University As a co-op student m 
college, ne developed an HP 41 calculator well log 
analysis module ior Petrophys.cal Data Consultants, 
an oil consulting tirm He |oined the Handheld Com- 
puter and Calculator Operation at HP's Portable Com- 
puter Division in 1985 He enjoys hiking with his wile 
and two beagles, gardening, philosophy, animal wel- 
fare, vegetarian cooking, home improvement 
eels, and science fiction 

Diana K. Byrne 

Diana Byrne is an R&D proj- 
ect manager in the Corvallis 
Design Center of HP's Asia 
Pacific Personal Computer 
Division She is responsible 
for managing a team of 
engineers split between 
Oregon and Singapore who 
are working on handheld 
products for education She was the project manager 
for the HP 38G graphing calculator Previously she 
was the project manager for the HP 48G/GX graphing 
calculator and contributed to the plot and graphics 
code She also worked as a software engineer on the 
HP 48SX scientific calculator for which she designed 
and implemented plot and graphics code and worked 
on the HP EquationWnter She is professionally inter- 
ested in the use of technology in education and has 
coauthored two papers on the HP 48G/GX and HP 
48SX calculators Diana was born in Portland. Oregon 
and earned a BS degree in mathematics with high 
honors in 1982 from Portland State University She 
went on to receive an MS degree in mathematics in 
1937 and an MS degree in computer science in 1988. 
both Irorn the University of Oregon Diana is currently 
enrolled in a Management o( Technology masters 
program at the National Technological University 
Before joining HP in 1988, she was a mathematics 
instructor at the University ol Oregon and Portland 
State University Diana has two snns She commutes 
to work by bicycle, telephone, or airplane (traveling 
to the Corvallis or Singapore sitel Her cutrent hobby 
is studying the coffeehouse culture in the U S and 
Europe 

James A. Donnelly 

Jim Donnelly inined HP's 
Corvallis Division in 1981 
and contributed to HP 75 
and HP 71 computer applica- 
tions and the HP 14. 22. 32, 
and 42 calculators He also 
worked on the HP 38G calcu- 
lator and the HP Solve equa- 
tion library card for the HP 
48SX Currently an R&D engineer in the Asia Pacific 
Personal Computer Division, he is responsible for the 
design of the next-generation handheld calculators 
and information appliances Recently he worked on 
ihe HP 38G calculator focusing an the numeric views, 
matrix catalog, matrix editor, list catalog, list editor. 
I/O. and priming, among other areas. He has wntten 
three books about programming the HP 48 and a soft- 
ware simulatoi Inr Babbaye's difference engine Jim 
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was awarded a BS degree m speech communication 
in 1979 from Oregon State University and worked on 
instrumentation software m the physics lab at the 
University of Oregon Bom m Chicago. Illinois. Jim is 
married and volunteers his time at the local commu- 
nity theater doing backstage work ana set and prop 
construction. His hobbies include travel photograph,, 
home machine shop, ana gardening 

Roben Ml Jones 

^ I Bom in Ml Vernon Wash 

f^T I a BS degree m mathematics 

^^^Lk^ajP^^ from the University tif W.*r 

'(^■7^ /j^B '" JIU " m ' 9 ' b He |0 "' fe ' HP 
■Hw^ I m 1982, writing documenta- 
tion for the HP41CXandHP 
28 calculators He also 
designed and implemented 
software for the HP 48SX and HP 48G/GX calculators 
As a software design engineer, he is currently 
responsible for software development for handheld 
products Recently he worked on the HP 38G home 
environment and user extensions to apiets He is pro- 
fessionally interested in functional programming and 
rational approximation. He authored a paper on the 
HP 48SX calculatoi and is named as an inventor in a 
patent involving interface design using menu keys 
and keypress duration He is a member of Ihe Mathe- 
matical Association of America and the Society for 
Industrial and Applied Mathematics Max is married 
and has two children His hobbies include New 
Orleans rhythm & blues 

Feng Yuan 

Born in Suzhou, Jiangsu in 
the Peuple's Republic of 
China, Feng Yuan was 
awarded a BE degree in 
electronics in 1982 from Ihe 
Shanghai University of Tech- 
nology al Shanghai and a 
masiers degree in computer 
science in 1984 and a PhD in 
computer engineering in 1987, both from Nanjing 
University at Nanjing. He became a lecturer at Nan- 
jing University doing teaching and research, ihen 
moved to Singapore to work on computer-aided 
embroidery pattern design software He joined HP's 
Asia Pacific Personal Computer Division in 1993 As 
an R&D engineer, he wnrked on the design and im- 
plementation of the HP 38G calculator, including the 
symbolic, note, and sketch views, sequence handling, 
statistical plots, external aplet examples, aplet rievel 
opment kit, and the Pascal compiler lor the HP 48 and 
HP 38 calculators, on which he published an ariicle 
He also wurked on the HP Palmtop FX computer, 
which is Ihe Korean flash version of the HP 100LX 
computer He is professionally interested in embedded 
system design, language processing and implementa- 
tion, computer-aided design, and artificial intelligence 
Feng is married and has one child His hobbies include 
reading and playing the Chinese board game Go. 

59 Creating HP 38G Apiets 
James A. Oonnelly 

Author's biography appeals elsewhere in this section 
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Edward H. Schmuhl 

■ 

^H^U manager for the PalmVue 
1^^^^ product family at HPs Pa- 
tient Monitoring Division 
(the successor to the Wai 
thani DtvisionI He is work 
mg with wireless -riome 

'hat deliver medical inform"-- — J cans ma 

hanoneld computers in his years at HP Ted has held 
various positions within product development includ- 
ing software engineer, project leader, and manager 
Some of his contributions have been the development 
of the architecture and software design for HP's first 
microprocessor-controlled patient monitoi, manage- 
ment of the design and integration of HP's CareNet 
patient monitoring network, and project management 
of the HP PalmVue project Before joining HP he 
worked at RCA Corporation developing automated 
test systems for the military He earned a BSEE 
degree from Tufts University in 1967 and an MSEi 
degree from Northwestern University in 1972 He is a 
member of the IEEE and is professionally interested 
in medical software and systems Born in Summit, 
New Jersey. Ted is married and has nne child He is 
active in his church and community An amateur 
musician, he plays trumpet in a local band. He also 
enjoys water sports such as sailing his 26-foot sail- 
boat 




Allan P. Sherman 

Born in Boston, Massachu- 
setts, Al Sherman received a 
BSME degree in 1961 and 
an MSME degree in 1981, 
both from the Worcester 
Polytechnic Institute He 
| joined Sanborn Company 
▼ I which was owned by HP, in 
^ ' 1964 and is curiently a soft- 
ware development engineer at HP's Patient Monitoring 
Division He was recently responsible for the palmtnp 
software design and for the data handling and com- 
munication architecture for HP PalmVue He contin- 
ues to woik on enhancements and extensions to the 
HP PalmVue system Previously he worked on the 
mechanical design of electronic, recording, and ana- 
lytical laboratory equipment He developed HP's first 
computer-based patient monitoring system and de- 
signed the pressure processing algorithm used in 
these systems He also provided software develop- 
ment for the early arrhythmia data management sys- 
tems He is named as the inventor In two patents on 
medical instrumentation and in three patents for 
blood pressure measurement techniques. He has 
authored two papers on arterial blood pressure mea- 
surement Before HP. he was an engineenrig msiruc 
tor at Western New England College in Springfield, 
Massachusetts He is a member of the Boston Com- 
putet Society and teaches classes there Al is married 
and has twu children His hobbies include computers, 
travel, and skiing. 
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Jon 0. Waisnor 

Jon Waisnor earned a BS 
degree in computer systems 
engineering from the Univer- 
sity of Massachusetts at 
Amherst in 1976 He worked 
as a software engineer at 
National Semiconductor and 
Wang Laboratories before 
joining HP's Patient Monitor- 
'«uttware ut/vi/i<*^nov>nt</>npi- 
neer. He recently worked on software specification, 
development, integration, and testing for HP Palm- 
Vue He is currently responsible for follow on versions 
of HP PalmVue and the integration of additional wire- 
less delivery systems Previously he worked an the 
HP M1275A component transport monitor, a bedside 
monitor Ethernet interface card, continuing product 
engineering, and arrhythmia analysis options for both 
the HP 78560A and HP M2300A central monitors He 
is professionally interested in software maintenance 
and program understandability tools. Born in Wake- 
field, Massachusetts. Jon is married and has two 
children In his free time he is the chairman of the 
local lawn hall computer study committee He also 
enjoys bicycling, skiing, gardening, jigsaw puzzles, 
and card games 
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Jill E. Swenson 

An information technology 
engineer at Corvallis Site 
Operations. Jill Swenson 
provides engineering sup- 
port for HP-UX workstations. 
For the server described in 
this issue, Jill provided the 
orimarv ifesign and tfnprir 
mentation of the configura- 
tion script for new software installation Previously 
she participated in a voice recognition and speech 
synthesis project She also provided engineering and 
technical support for PC developers. In addition, she 
supplied software distribution services to HP-wide 
LM/X servers including designing and documenting 
the distribution process, supporting the PC applications 
and distribution mechanism, and doing application 
development. Jill was born in San Francisco and 
received a BA degree in molecular biology in 1986 
from the University of California. Berkeley She jefeed 
HP Laboratories in 1981. She is married and her hob- 
bies include gardening, cooking, home improvement, 
and exploring backroads 
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James R Buffenbarger 



Jim Buffenbarger is a shared 
prolessor in computer sci- 
ence for HP and Boise State 
University He joined HP's 
Boise Printer Division in 
1991. At HP. he is focusing 
on software engineering and 
_ software configuration man- 
* agement at the Color Laser- 
Jet and Coi. 'mables Division He is professionally 
interested in sou.VoTC 0 engineering, programming 
languages, and programming 'anguage translation 
He is a member of the IEEE and the Ai"M. Jim earned 
a BS degree in computer science from Can. 'orma State 
University at Hayward, an MS degree in compu 'tar 
science from San Jose State University, and a PhD iM 
computer science from the University of California at 
Davis. He was born in West Covma, California, is 
married, and has one daughter He enjoys ouidoor 
sports such as camping, fishing, snow skiing, and 
water skiing. 
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Digital System Integration 



Patrick J Byrne 

As R&D manager at HPs 
Colorado Springs Division 
Pat Bvrne is responsible tor 
logic analyzers, emulators, 
and digital system solutions 
Born in Palo Alto. California, 
he earned a BSEE degree in 
1982 from the University of 
California at Berkeley and an 
MSEE degree in 1988 from Stanford University He 
loined HP's Integrated Circuits Business Division in 
1983 and worked as an R&D project and section 
manager from 1986 to 1991 designing custom inte- 
grated circuits for HP printers, computers, instru- 
ments, and communications products In 1991, he 
became an R&D section manager for logic analyzers 
and emulators at the Colorado Springs Division He 
was the R&D section manager for the HP 16S05A 
prototype analyzer He is professionally interested >n 
digital system development tools and processes and 
has authored two articles on logic analyzers He is 
named as an inventor in a pending patent on configu- 
rable logic measurement systems Pat is married and 
has three children He enpys uutdoor sports such as 
golf, mountain biking, cross-country skiing, and soccer. 

15 Prototype Analyzer Architecture 



Jeffrey E. Roeca 

Jeff Roeca is an R&D project 
manager at HP's Colorado 
Springs Division He was a 
software contributor for the 
diag-and-drop GUI. fileout. 
and system level soflware 
for the HP 16505A prototy|>e 
S ' analyzer and currently man 
^* ages the software develop- 

ment elfori Jeff joined HP in 1989 and has wurked 
on the HP 16500 system soltware. the HP 1660 Ul 
design las principal designer), and the HP 16505A 
software design He was awarded a BS degree in 
applied mathematics at California Polytechnic State 
University at San Luis Obispo Before HP. he worked 
at HOLM Corporation on fault tolerant switching soft- 
ware, database integrity software, and telephony 
feature software Born in Encino. California. JeH is 
married and has three children His hobbies include 
skiing, tennis, biking, hiking, and music 
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Gregory J Peters 

H Born in Cedar RapiO 
M- -arned a BSEE 

| from Iowa Stan 

ft. In May 1984 
» s » I joined HFs Colorado Springs 
\ 1 Division that June. He has 

e^- provided technical support 

f&yu „ for HP pulse pattern, IC test, 

and optical test products, 
assisted in defining the pattern generator and other 
measurement modules for the HP 16500 system, and 
participated in market investigation, definition, and 
introduction of products that now form the core of 
HPs digital prototyping solutions Part of his respon- 
sibility was to act as the contact with HP's Work- 
station Division on sourcmg issues He is currently 
the lead product marketing engineer for the HP 16500 
system including measurement modules and the HP 
16505A prolotype analyzer He has authored four 
articles on logic analyzers and pattern generators. In 
1991 he earned an MBA degree from the University 
of Colorado at Colorado Springs In his free time, 
Greg enjoys mountain biking, skiing, golf, volleyball, 
and travel, especially international travel thai mixes 
sightseeing and biking He is also involved in local 
trail maintenance activities 

30 Normalized Data Library 

Mark P. Schnaible 




I Mark Schnaible loined HP's 
A Colorado Springs Division in 
I 1988 after receiving a BSEE 
I degiee liorn Ohio State Urn- 
I versity He is currently a 
I software engineer In R&0 
' working on the HP 16505A 
prototype analyzer software 
and assisting with other 
projects He recently was responsible for the proto- 
type analyzer s normalized data library and was a 
major contributor to the overall architecture Previously 
he worked on the HP 54600 series of oscilloscopes 
and is named as the inventor in a patent related to 
the user interface software used in the oscilloscopes 
Mark is married and has three sons In his fiee time, 
he has taught object-oriented programming using 
C** at the University of Colorado at Colorado 
Springs He also enjoys sottball, basketball. Skiing, 
golf, and family life 




38 HP OmniBook 5000 Computer 



Timothy F. Myers 

Tim Myers is a hardware 
design engineer at HPs 
Mobile Computing Division 
He is currently responsible 
for the electrical engineering 
ol new products for the 
notebook computer market 
Recently he was the lead 
system engineer foi the HP 
OmniBook 5000 computer He has also worked on the 
electrical engineering for the OmniBook 425 and HP 
75C computers including IC design and system manu- 
facturing support He is a member of the IEEE and is 
a licensed physical engineer in the State of Oregon 
His professional interests include mobile computing 
and spread-spectrum communications on which he 
has authored several articles He received a BSEE 
degree in 1979 from Montana State University and 
an MSEE degree in 1992 from Oregon State Univer- 
sity where he was a teaching assistant He loined 
HP's Corvallis Division m 19/9. then left, reluming in 
1992 He has also worked at Fortune Systems as an 
engineering manager and at Corvallis Microler.hnol- 
ogy as a vice president lor product strategy. Tim was 
born in Fort Collins. Colorado He is married and has 
two sons His hobbies include totting, reading, 
investing, fishing, and exploring Oregon's mountains 
and beaches 
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Ted W. Beers 

■ Ted Beem is a software R&O 

^^^H engineer in the Corvallis 
[ ■ 1 'P's Asia 

\~ ~ f Pacific Personal Computer 

^ L 

'Jl lor the next-gene: • •" 

(I products tor edu- 

^^^^E^^^^M die 

Internet communication tools He lecently worked on 
the HP 38G calculator including graphical user inter- 
face enhancements, the topic outer loop, and Hie 
aplet library He worked on the HP 48G/GX, develop- 
ing the graphical user interface He co-developed the 
Program Development Lmk product, a PC develop- 
ment environment foi HP 48S/SX applications. He 
wnrked on the HP 48S/SX. focusing on the parame- 
terized outer loop, interactive stack, key handing sys- 
tem, user customization, and high-level display man- 
agement He also contributed to the directory 
structure and user memory organizalion for the HP 
28S and the testing for the HP 2BC Professionally 
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about 27") files occupying over L3 megabytes. About one 
quarter of these files contain (' source code, while the rest 
contain assembly-language source code. The t ranslat or is 
used on about - 1* » include files. 

For the most pail, the experiences and comments of those 
involved have been positive. Surprisingly, arithmetic-over- 
flow checking caused problems, because the target assem- 
bler's word size depends on t he complexity of an expression 
(operator-free expressions can be large), hi addition, several 
users requested an output-file preamble of comments. These 
comments contain file names, version numbers, and time 
stamps. 

The vast majority of difficulties have been with build pro- 
cess integration rather than translation. Users have had 
trouble understanding and correctly using the prior-inclusion 
preprocessor. Typically, a file containing a typedef is omitted, 
which causes the parser to produce a parse error message. 
In addition, a .inc file's dependence on its corresponding h 
file is not properly recognized by the mechanism responsible 
for automatically checking out the h file from the version 
control system. 
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